TiDB 6.0 Placement Rules In SQL 使用实践

2023-10-11 01:59
文章标签 sql tidb 使用 实践 6.0 rules database placement

本文主要是介绍TiDB 6.0 Placement Rules In SQL 使用实践，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

本文作者：吴永健 https://tidb.net/u/banana_jian

简介

TiDB 6.0 版本正式提供了基于 SQL 接口的数据放置框架（Placement Rules in SQL）， 特性用于通过 SQL 接口配置数据在 TiKV 集群中的放置位置。通过该功能，用户可以将表和分区指定部署至不同的地域、机房、机柜、主机。适用场景包括低成本优化数据高可用策略、保证本地的数据副本可用于本地 Stale Read 读取、遵守数据本地要求等。它支持针对任意数据提供副本数、角色类型、放置位置等维度的灵活调度管理能力，这使得在多业务共享集群、跨 AZ 部署等场景下，TiDB 得以提供更灵活的数据管理能力，满足多样的业务诉求。

该功能可以实现以下业务场景：

  • 合并多个不同业务的数据库，大幅减少数据库常规运维管理的成本
  • 增加重要数据的副本数，提高业务可用性和数据可靠性
  • 将最新数据存入 SSD，历史数据存入 HDD，降低归档数据存储成本
  • 把热点数据的 leader 放到高性能的 TiKV 实例上
  • 将冷数据分离到不同的存储中以提高可用性

使用放置规则时有 2 种方式

(1) 直接放置

直接放置是指在 create table 时或使用 alter table 方式直接在表的 DDL 语句中使用放置选项

create table jian(id int) primary_region='bj' folllowers=4

(2) 放置策略

使用放置策略时首先通过 create placement policy 建立放置策略，然后在 create table 或 alter table 中直接指定放置策略。

create placement policy location_policy primary_region='bj' folllowers=4;alter table jian placement policy location_policy;

使用时： 创建放置策略会使 placement policy 更加易于管理，通过修改放置策略可以直接更新所有使用该策略的对象。另一方面对于 create table 时使用和 alter table 时指定，这里也建议大家能注意以下两点：

  1. create 方式建议在项目初期的库表结构设计节点进行设定，那么在初始话项目数据库的时候可以一次成型。否则需要将整个表进行recreate，此处就需要考虑历史数据的问题。

  2. alter 方式由于是使用ALTER进行修改当表数据量大的时候可能会产生大量数据peer的移动，可能会消耗一定的资源，建议在业务低峰进行，但是也较好地弥补了一些即存表没有进行放置规则的设定后期需要添加，或者版本升级后需要使用新特性的问题。

Placement Rules in SQL 的应用场景猜想

由于 Placement Rules in SQL 的灵活性，在使用时可以“因地适宜”。以下是几个可以考虑的场景：

  1. 当采取两地三中心或跨地域数据中心部署的时候，由于 tidb 是无状态的应用那么可以利用就近原则将业务接入点进行分块，同时对于数据的分布也可以采用同样的方式。使数据的存放可以达到“本地数据本地访问”，即所有的数据存储，管理在本地区内完成。减少了数据跨地区复制延迟，降低流量成本。

  2. 当系统 IO 存在某些瓶颈时可以考虑将某些 tikv 节点的数据盘更换为 SSD，之后经过 Placement Rules 动态调整数据副本的存放策略，提高 db 的 IO 性能。对于一些历史及记录类的数据可以选择存放在一些主要由普通硬盘构成的 tikv 节点上。使硬件资源的配置得到充分的利用，而又不铺张浪费。

  3. 同时也考虑当进行硬件更换时可以使用 Placement Rules 对数据分布进行调整以减小 tikv 节点下线时的 peer 移动所需要的时间，因为通过 Placement Rules 可以将数据移动的动作提前进行分散在平时的小维护中。

  4. 由于数据的重要程度不同对于以往的副本设置可能更偏向于全局，引入 Placement Rules in SQL 后对于数据的副本数就可以进行灵活的限定，对高要求的数据表进行多副本设置，对于不太紧要的表尽量的减小副本数，在保证数据的安全性的情况下又可以节约存储资源。

  5. 如果业务采用了分库的模式为了减少运维成本，那么也可以考虑进行数据库整合，将分散的 mysql 实例迁移到一个 Tidb 集群中以多 schema 的方式存在，同时根据 Placement Rules 原始业务数据库的数据存放节点仍然可以放置在原来的硬件节点上，但是逻辑上由于整合到了一个数据库集群中升级、打补丁、备份计划、扩缩容等日常运维管理频率可以大幅缩减，降低管理负担提升效率。

  6. 对于经典的热点问题在 Placement Rules in SQL 也添加了更多的解决方案，通过 Placement Rules in SQL 也可以进行热点表的分布调整，而且也更加的方便与安全。虽然不能精确到 region 的级别，但是在表的粒度上也多提供了一种处理方法。

下面我们来详细看看 placement policy 的使用方法：

当前 tikv 节点以及集群的信息如下：

ID                     Role          Host             Ports        OS/Arch       Status   Data Dir                      Deploy Dir\--                     ----          ----             -----        -------       ------   --------                      ----------192.168.135.148:9093   alertmanager  192.168.135.148  9093/9094    linux/x86_64  Up       /tidb-data/alertmanager-9093  /tidb-deploy/alertmanager-9093192.168.135.148:3000   grafana       192.168.135.148  3000         linux/x86_64  Up       -                             /tidb-deploy/grafana-3000192.168.135.148:2379   pd            192.168.135.148  2379/2380    linux/x86_64  Up|L|UI  /tidb-data/pd-2379            /tidb-deploy/pd-2379192.168.135.148:9090   prometheus    192.168.135.148  9090/12020   linux/x86_64  Up       /tidb-data/prometheus-9090    /tidb-deploy/prometheus-9090192.168.135.148:4000   tidb          192.168.135.148  4000/10080   linux/x86_64  Up       -                             /tidb-deploy/tidb-4000192.168.135.148:20160  tikv          192.168.135.148  20160/20180  linux/x86_64  Up       /tidb-data/tikv-20160         /tidb-deploy/tikv-20160192.168.135.148:20161  tikv          192.168.135.148  20161/20181  linux/x86_64  Up       /tidb-data/tikv-20161         /tidb-deploy/tikv-20161192.168.135.148:20162  tikv          192.168.135.148  20162/20182  linux/x86_64  Up       /tidb-data/tikv-20162         /tidb-deploy/tikv-20162

这里有一点需要大家注意一下：默认的 PLACEMENT POLICY 是需要以 region 来作为区分标签的，所以在创建 tikv 的时候这里需要明确的指定 tikv 的 region 的标签，不然的话在show placement labels 是无法看到 region lable 的。这里可以参照官方文档的建议

PLACEMENT RULES的使用

1. 创建 PLACEMENT POLICY，并指定 PLACEMENT POLICY，定制其副本放置的位置

这里创建一个 PLACEMENT POLICY 使其 PRIMARY_REGION 放置在 region lable 为 bj 的 tikv 节点上，其余副本放置在 region lable 为 dl,sz 的 tikv 节点上

注意：primary region 必须包含在 region 的定义中

此处的 Raft leader 在 4 号 store 上，看之前开头的环境信息可以验证 PLACEMENT POLICY 已经生效


(root\@127.0.0.1) \[test] 12:00:14> CREATE PLACEMENT POLICY jianplacementpolicy PRIMARY_REGION="bj" REGIONS="bj,dl,sz";Query OK, 0 rows affected (0.10 sec)(root\@127.0.0.1) \[test] 12:00:32> CREATE TABLE jian1 (id INT) PLACEMENT POLICY=jianplacementpolicy;Query OK, 0 rows affected (0.10 sec)(root\@127.0.0.1) \[test] 12:03:36> show table jian1 regions\GREGION_ID: 135START_KEY: t_68\_END_KEY: t_69\_LEADER_ID: 137LEADER_STORE_ID: 4    这里可以看到store_id是4                                PEERS: 136, 137, 138SCATTERING: 0WRITTEN_BYTES: 39READ_BYTES: 0APPROXIMATE_SIZE(MB): 1APPROXIMATE_KEYS: 01 row in set (0.00 sec)

2. 创建表不指定 PLACEMENT POLICY，之后修改 PLACEMENT POLICY 定制其副本放置的位置

leader 的 store 节点由原来的 1 变为了 4，看之前开头的环境信息可以验证 PLACEMENT POLICY 已经生效,可使用这个特性来修改表的leader节点或者当有热点问题时也可以变相的通过这种方式去修改频繁访问的表的leader所在的tikv的节点位置

(root\@127.0.0.1) \[test] 12:03:39> create table jian2(id int);Query OK, 0 rows affected (0.10 sec)(root\@127.0.0.1) \[test] 12:05:14> show table jian2 regions\G\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\* 1. row \*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*REGION_ID: 2START_KEY: t_70\_END_KEY:LEADER_ID: 3LEADER_STORE_ID: 1PEERS: 3, 63, 85SCATTERING: 0WRITTEN_BYTES: 0READ_BYTES: 0APPROXIMATE_SIZE(MB): 1APPROXIMATE_KEYS: 01 row in set (0.00 sec)(root\@127.0.0.1) \[test] 12:05:16> alter table jian2  PLACEMENT POLICY=jianplacementpolicy;Query OK, 0 rows affected (0.09 sec)(root\@127.0.0.1) \[test] 12:05:50>  show table jian2 regions\G\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\* 1. row \*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*REGION_ID: 143START_KEY: t_70\_END_KEY: t_71\_LEADER_ID: 145LEADER_STORE_ID: 4                       PEERS: 144, 145, 146SCATTERING: 0WRITTEN_BYTES: 0READ_BYTES: 0APPROXIMATE_SIZE(MB): 1APPROXIMATE_KEYS: 01 row in set (0.00 sec)

3. 通过 PLACEMENT POLICY 修改表的副本数

Follower 的数量。例如 FOLLOWERS=2 表示数据有 3 个副本（2 个 follower 和 1 个 leader）。

(root\@127.0.0.1) \[test] 12:10:34> alter  PLACEMENT POLICY jianplacementpolicy FOLLOWERS=1;Query OK, 0 rows affected (0.11 sec)(root\@127.0.0.1) \[test] 12:10:40>  show table jian2 regions\G\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\* 1. row \*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*REGION_ID: 143START_KEY: t_70\_END_KEY: t_71\_LEADER_ID: 145LEADER_STORE_ID: 4PEERS: 144, 145                    **副本数从 3 个已经调整到了 2 个
**SCATTERING: 0WRITTEN_BYTES: 0READ_BYTES: 0APPROXIMATE_SIZE(MB): 1APPROXIMATE_KEYS: 01 row in set (0.00 sec)(root\@127.0.0.1) \[test] 12:10:44> alter  PLACEMENT POLICY jianplacementpolicy FOLLOWERS=2;Query OK, 0 rows affected (0.09 sec)(root\@127.0.0.1) \[test] 12:10:59>  show table jian2 regions\G\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\* 1. row \*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*REGION_ID: 143START_KEY: t_70\_END_KEY: t_71\_LEADER_ID: 145LEADER_STORE_ID: 4PEERS: 144, 145, 148SCATTERING: 0WRITTEN_BYTES: 0READ_BYTES: 0APPROXIMATE_SIZE(MB): 1APPROXIMATE_KEYS: 01 row in set (0.02 sec)

4. 修改 PLACEMENT POLICY 定义

注意：修改定义时需要将原来的定义都带上否则会将其覆盖 这一点在官方文档中并没有特殊说明，也是自己在测试这个功能的时候偶然的发现，目前官方也没有直接修改的语法，所以大家在修改放置规则的时候一定要注意之前的定义以免将之前的定义覆盖。

##########################################################
之前的 PRIMARY_REGION="bj" REGIONS="bj,dl,sz" 定义已经被覆盖了
##########################################################

5. PRIMARY_REGION 节点宕机

如果 PRIMARY_REGION 的 tikv 节点宕机，那么 leader 节点也会转移到非 PRIMARY_REGION 节点，当 tikv 节点恢复正常后 leader 节点也会随之转移回来

以下的过程

leader 节点：store4-- 停止 store 的 tikv —》store1 – 恢复 tikv 节点-- 》store4

6. 更改 PRIMARY_REGION

如果更改表当前 palcement policy 定义的 primary region 那么表的 leader 也会随 PRIMARY_REGION 的改变而改变

下图 jian1 表一开始的 region 1005 的 leader 是在 store4（bj）上边,之后修改其 PRIMARY_REGION 为 dl(store 1),可以看到 region 1005 的 leader 也确实随之发生了改变

7. PLACEMENT POLICY 同样适用与分区表

以下样例中我们手动指定了每一个分区的 PLACEMENT POLICY，使其每个分区的 leader 都存放于不同的 store 上。

CREATE PLACEMENT POLICY policy_table FOLLOWERS=3;CREATE PLACEMENT POLICY policy_dl PRIMARY_REGION="dl" REGIONS="dl,bj,sz";CREATE PLACEMENT POLICY policy_bj PRIMARY_REGION="bj" REGIONS="dl,bj,sz";CREATE PLACEMENT POLICY policy_sz PRIMARY_REGION="sz" REGIONS="dl,bj,sz" FOLLOWERS=1;SET tidb_enable_list_partition = 1;CREATE TABLE t1 (location VARCHAR(10) NOT NULL,userdata VARCHAR(100) NOT NULL) PLACEMENT POLICY=policy_table PARTITION BY LIST COLUMNS (location) (PARTITION p_dl VALUES IN ('dl') PLACEMENT POLICY=policy_dl,PARTITION p_bj VALUES IN ('bj') PLACEMENT POLICY=policy_bj,PARTITION p_sz VALUES IN ('sz') PLACEMENT POLICY=policy_sz);

下图可一看到t1的region分别存放在store 1(dl),4(bj),5(sz)上边

8. 查看数据库中现有的 PLACEMENT POLICY

9. 设置数据库级别的 PLACEMENT POLICY

更改默认的放置选项，但更改不影响已有的表

创建新表会自动继承当前数据的放置规则

表级别的放置规则要优先于数据库级别的放置规则

10. 高级放置规则

注意：PRIMARY_REGION、REGIONS 和 SCHEDULE 选项不可与 CONSTRAINTS 选项同时指定，否则会报错

以下 placement policy 的解读为：

  1. 使用该规则的表的 region 只可以放置在含有 rack 标签且等于 rack1 的 tikv 节点上
  2. 使用该规则的表的 leader region 只可以放置在含有 dc 标签且等于 bja 的 tikv 节点上
  3. 使用该规则的表的 follower region 只可以放置在含有 dc 标签且等于 dla 的 tikv 节点上

(root\@127.0.0.1) \[(none)] 16:34:28>  create placement policy localtion_policy CONSTRAINTS="\[+rack=rack1]" LEADER_CONSTRAINTS="\[+dc=bja]" FOLLOWER_CONSTRAINTS="{+dc=dla: 1}";Query OK, 0 rows affected (0.10 sec)(root\@127.0.0.1) \[(none)] 16:35:41> create table testdb.jian2(id int) placement policy=localtion_policy;Query OK, 0 rows affected (0.19 sec)(root\@127.0.0.1) \[(none)] 16:35:49> show table testdb.jian2 regions\G\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\* 1. row \*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*REGION_ID: 1127START_KEY: t_167\_END_KEY: t_168\_LEADER_ID: 1129LEADER_STORE_ID: 4PEERS: 1128, 1129SCATTERING: 0WRITTEN_BYTES: 0READ_BYTES: 0APPROXIMATE_SIZE(MB): 1APPROXIMATE_KEYS: 01 row in set (0.01 sec)

注意：虽然 placement policy 高级匹配规则的默认 followers 是 2（三副本）但是实际的副本数还是要看符合 lable 的 tikv 的数量,如果实际的tikv节点数量无法满足2followers 那么最终也只会有两个副本（也就是只有一个followers和一个leader）上边的查询结果可以看到实际 region 的副本只有两个，但是当查询 localtion_policy 这个规则定义的时候 followers 为 2

POLICY_ID: 17CATALOG_NAME: defPOLICY_NAME: localtion_policyPRIMARY_REGION:REGIONS:CONSTRAINTS: \[+rack=rack1]LEADER_CONSTRAINTS: \[+dc=bja]FOLLOWER_CONSTRAINTS: {+dc=dla: 1}LEARNER_CONSTRAINTS:SCHEDULE:FOLLOWERS: 2LEARNERS: 0

11. placement policy 的创建选项

选项名描述
PRIMARY_REGIONRaft leader 被放置在有 region 标签的节点上，且这些 region 标签匹配本选项的值。
REGIONSRaft followers 被放置在有 region 标签的节点上，且这些 region 标签匹配本选项的值。
SCHEDULE用于调度 follower 放置位置的策略。可选值为 EVEN（默认值）或 MAJORITY_IN_PRIMARY。
FOLLOWERSFollower 的数量。例如 FOLLOWERS=2 表示数据有 3 个副本（2 个 follower 和 1 个 leader）。
CONSTRAINTS适用于所有角色 (role) 的约束列表。例如，CONSTRAINTS=“[+disk=ssd]”。
LEADER_CONSTRAINTS仅适用于 leader 的约束列表。
FOLLOWER_CONSTRAINTS仅适用于 follower 的约束列表。
LEARNER_CONSTRAINTS仅适用于 learner 的约束列表。
LEARNERS指定 learner 的数量。

12. 删除 placement policy

删除 placement policy 时一定要确保没有任何表在使用当前的 placement policy 否则会报错

(root\@127.0.0.1) \[test] 12:11:43> drop PLACEMENT POLICY jianplacementpolicy;ERROR 8241 (HY000): Placement policy 'jianplacementpolicy' is still in use(root\@127.0.0.1) \[test] 12:16:20> alter table jian1 PLACEMENT POLICY=default;Query OK, 0 rows affected (0.08 sec)

查看某个 placement policy 是否正在被表使用

SELECT table\_schema, table\_name FROM information\_schema.tables WHERE tidb\_placement\_policy\_name='jianplacementpolicy';SELECT table\_schema, table\_name FROM information\_schema.partitions WHERE tidb\_placement\_policy\_name='jianplacementpolicy';

总结

当前版本在使用 Placement Rules in SQL 时如果使用基本的放置规则那么只可以使用 PRIMARY_REGION 和 REGIONS 来进行放置规则的设置，但是如果使用高级放置规则那么 tikv 的 label 标签不需要必须设置 region 层级的标签，可以灵活使用和定义已存在或者需要的标签。

高级放置规则的默认 followers 的数量为 2，但是如果在设置规则 FOLLOWER_CONSTRAINTS 时如果满足的节点不满足 2 时只会在 FOLLOWER_CONSTRAINTS 匹配的节点上创建副本，这一点在创建时一定要规划好自己的集群中的 tikv 节点的标签设计，以免导致 region 的副本数过少。

Placement Rules in SQL 可以通过它对分区 / 表 / 库不同级别的数据进行基于标签的自由放置。

总之 TiDB 6.0 的 Placement Rules In SQL 暴露了以往用户无法控制的内部调度能力，并提供了方便的 SQL 接口，这开启了诸多以往不可能实现的场景，更多的运用方式与使用场景还期待各位的发掘。

这篇关于TiDB 6.0 Placement Rules In SQL 使用实践的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！


http://www.chinasem.cn/article/184720。

相关文章

SQL中的外键约束

SQL中的外键约束

外键约束用于表示两张表中的指标连接关系。外键约束的作用主要有以下三点： 1.确保子表中的某个字段（外键）只能引用父表中的有效记录2.主表中的列被删除时，子表中的关联列也会被删除3.主表中的列更新时，子表中的关联元素也会被更新 子表中的元素指向主表 以下是一个外键约束的实例展示
阅读更多...
基于MySQL Binlog的Elasticsearch数据同步实践

基于MySQL Binlog的Elasticsearch数据同步实践

一、为什么要做 随着马蜂窝的逐渐发展，我们的业务数据越来越多，单纯使用 MySQL 已经不能满足我们的数据查询需求，例如对于商品、订单等数据的多维度检索。 使用 Elasticsearch 存储业务数据可以很好的解决我们业务中的搜索需求。而数据进行异构存储后，随之而来的就是数据同步的问题。 二、现有方法及问题 对于数据同步，我们目前的解决方案是建立数据中间表。把需要检索的业务数据，统一放到一张M
阅读更多...
如何去写一手好SQL

如何去写一手好SQL

MySQL性能 最大数据量 抛开数据量和并发数，谈性能都是耍流氓。MySQL没有限制单表最大记录数，它取决于操作系统对文件大小的限制。 《阿里巴巴Java开发手册》提出单表行数超过500万行或者单表容量超过2GB，才推荐分库分表。性能由综合因素决定，抛开业务复杂度，影响程度依次是硬件配置、MySQL配置、数据表设计、索引优化。500万这个值仅供参考，并非铁律。 博主曾经操作过超过4亿行数据
阅读更多...
中文分词jieba库的使用与实景应用（一）

中文分词jieba库的使用与实景应用（一）

知识星球：https://articles.zsxq.com/id_fxvgc803qmr2.html 目录 一.定义： 精确模式（默认模式）： 全模式： 搜索引擎模式： paddle 模式（基于深度学习的分词模式）： 二 自定义词典 三.文本解析   调整词出现的频率 四. 关键词提取 A. 基于TF-IDF算法的关键词提取 B. 基于TextRank算法的关键词提取
阅读更多...
使用SecondaryNameNode恢复NameNode的数据

使用SecondaryNameNode恢复NameNode的数据

1）需求： NameNode进程挂了并且存储的数据也丢失了，如何恢复NameNode 此种方式恢复的数据可能存在小部分数据的丢失。 2）故障模拟 （1）kill -9 NameNode进程 [lytfly@hadoop102 current]$ kill -9 19886 （2）删除NameNode存储的数据（/opt/module/hadoop-3.1.4/data/tmp/dfs/na
阅读更多...
Hadoop数据压缩使用介绍

Hadoop数据压缩使用介绍

一、压缩原则 （1）运算密集型的Job，少用压缩 （2）IO密集型的Job，多用压缩 二、压缩算法比较 三、压缩位置选择 四、压缩参数配置 1）为了支持多种压缩/解压缩算法，Hadoop引入了编码/解码器 2）要在Hadoop中启用压缩，可以配置如下参数
阅读更多...
Makefile简明使用教程

Makefile简明使用教程

文章目录 规则makefile文件的基本语法：加在命令前的特殊符号：.PHONY伪目标: Makefilev1 直观写法v2 加上中间过程v3 伪目标v4 变量 make 选项-f-n-C Make 是一种流行的构建工具，常用于将源代码转换成可执行文件或者其他形式的输出文件(如库文件、文档等)。Make 可以自动化地执行编译、链接等一系列操作。 规则 makefile文件
阅读更多...
性能分析之MySQL索引实战案例

性能分析之MySQL索引实战案例

文章目录 一、前言二、准备三、MySQL索引优化四、MySQL 索引知识回顾五、总结 一、前言 在上一讲性能工具之 JProfiler 简单登录案例分析实战中已经发现SQL没有建立索引问题，本文将一起从代码层去分析为什么没有建立索引？ 开源ERP项目地址：https://gitee.com/jishenghua/JSH_ERP 二、准备 打开IDEA找到登录请求资源路径位置
阅读更多...
使用opencv优化图片（画面变清晰）

使用opencv优化图片（画面变清晰）

文章目录 需求影响照片清晰度的因素 实现降噪测试代码 锐化空间锐化Unsharp Masking频率域锐化对比测试 对比度增强常用算法对比测试 需求 对图像进行优化，使其看起来更清晰，同时保持尺寸不变，通常涉及到图像处理技术如锐化、降噪、对比度增强等 影响照片清晰度的因素 影响照片清晰度的因素有很多，主要可以从以下几个方面来分析 1. 拍摄设备 相机传感器：相机传
阅读更多...
MySQL数据库宕机，启动不起来，教你一招搞定！

MySQL数据库宕机，启动不起来，教你一招搞定！

作者介绍：老苏，10余年DBA工作运维经验，擅长Oracle、MySQL、PG、Mongodb数据库运维（如安装迁移，性能优化、故障应急处理等）公众号：老苏畅谈运维欢迎关注本人公众号，更多精彩与您分享。 MySQL数据库宕机，数据页损坏问题，启动不起来，该如何排查和解决，本文将为你说明具体的排查过程。 查看MySQL error日志 查看 MySQL error日志，排查哪个表（表空间
阅读更多...

Copyright China编程 23002807@qq.com

沪ICP备2023033072号-2