|
|
51CTO旗下网站
|
|
移步端
  • 为什么我们要下MySQL搬迁到TiDB?

    顶一张百亿数目量的外表放在你面前,你将面临着什么?加列?哭吧,怎么也得等个几角甚至几周。加索引?哭吧,无论是你用 pt-online-schema,还是 gh-ost,你都面临着拷贝一张临时表用以存储临时数据,光盘已经 80% 了,这一张表就占几百 G,你咋弄?

    笔者:贺磊 来源:51CTO艺术栈| 2020-03-12 08:00

    【国民经济特辑】光大银行科技部DBA女神带你从0到1揭露MGR

    【51CTO.com原创稿件】顶一张百亿数目量的外表放在你面前,你将面临着什么?加列?哭吧,怎么也得等个几角甚至几周。加索引?哭吧,无论是你用 pt-online-schema,还是 gh-ost,你都面临着拷贝一张临时表用以存储临时数据,光盘已经 80% 了,这一张表就占几百 G,你咋弄?

    图表来自 Pexels

    我先说几个最让你兴奋和开心的线吧:

  • 在 TiDB 阴,你完全不用担心磁盘容量的题材。
  • 在 TiDB 阴,原生支持 Online DDL,你完全不用担心第三方改表工具改表出现各种 Bug 的题材,相信用开源工具改过上 T 级别表的同窗都遇到过一些的各个 error。
  • 在 TiDB 阴,加列,东道主键扩容字段都是秒级的,比如我刚刚就刚对一张 19 京之外表加完了字段,1 秒完事,这在 MySQL 阴要 8.0 才得以,而且还要求列在最后才行。
  • 在 TiDB 阴,你会发现 count(*) 震惊之快,一张近 20 京之外表 coun(*) 简言之在 1 分钟完事儿,当然,这取决于你的 KV 多少和录像带性能。
  • 在 TiDB 阴,副 MySQL 搬迁将变得简单,图片化一键迁移,爽不爽?
  • 在 TiDB 阴,大多数状态你会发现比单机 MySQL 有更好的性质,当然也不排除一些奇异,例如 enum 这样奇葩的字段类型。
  • 在 TiDB 阴,......,您且往下看,我慢慢和您说。
  • 采用背景

    360 云平台对 360 集团各大工作线均有提供服务支持,涉及的必发娱乐登录支持方案有:MySQL、Redis、MongoDB、ES、GP、PiKA。

    其中 MySQL 至此已有过万之范例,脚下,对于一些写入量大的工作,已经出现瓶颈。

    例如磁盘空间,虽然我们可以通过分库分表的措施,拆分出来,但这对工作和 DBA 来说都是不小的总量,最痛苦的无异于那些大表的改表。

    不论单表上 T,还是分库分表,对一张大表执行 DDL 的平价是异样大的。

    针对业务爆发式增长之多寡量,咱们开始调研选型是否有其它必发娱乐登录可以取代传统的 MySQL。

    穿过调研我们了解到 TiDB,搬迁平滑,基本上无需业务变动代码,总体的工作 ACID 支持,分布式的架构,自带高可用、Online DDL。

    截止目前,360 云平台这边有三套 TiDB 集群,总节点数在 50+。有 9 个工作线接入使用,有过百亿级表 Online 加索引的老,总数据量目前在 80T。

    本子上,咱们从 3.0.1 一路跟随到 3.0.5,DM 本子从内测到 1.0.2 GA 本子,累计提出 9 个 Bug 或改进项反馈。

    持续我们计划将 TiDB 上到 360 HULK 云平台上,并录制化开发一些功能为工作提供可视化的劳务,以便让 360 集团更多的工作线接触到 TiDB、采用 TiDB。

    本子的取舍我们之所以从大本子 3 起来,也是看到了部分 2.X 本子的农牧区反馈,尤其是索引执行计划这块,3.X 本子较之前的本子会好很多。DM 本子我们是直接选取的最新版,此后一路跟随新版本升级。

    集群架构

    完全架构上,咱们除了 TiDB 集群外,还利用了 DM 和 Pump、Drainer 套件。

    这块主要是出于我们采用 TiDB 的工作有两种:

    ①成熟的 MySQL 工作,因单机磁盘受限,导致单实例磁盘无法支撑爆炸式增长之多寡量,数量比较重要,要求维修和支持 7*24 小时之恢复。

    这类事情我们利用 DM 套件来促成无障碍迁移,1TB 的导入时间在 16 小时,此地如果是比较大的数据源,且 TiDB 是全新集群,可以运用 TiDB-Lightning,速度可以更快。

    Lightning 的探测导入速度,37 分钟,导完 2 张大表共计 54G 的多寡,符合 100G/H 预估,是 loader 的 3 倍速度,loader 用时 2 小时 4 分钟。

    说起 DM 采用这块文章后面会单独分享下这块需要注意的题材,如下图所示:

    ②全新的工作,或由业务自行导入到 TiDB 集群中,这种业务数据量一般都会比较大,也是满意了 TiDB 支持 ACID 和分布式的性状。

    脚下网盾业务有多张表都过 10 京级别,其中有张表到达了 100 京+,建索引花了近 10 远处(这块其实我们应有注意,不是分布式就一张表就完成儿了,因为表量级过大,清理老旧数据都是个问题)。

    TiDB 如今支持分区表,但我们在采取过程中发现性能上和一般表有差异,希望后续版本能够让分区表功能和总体性更加的宏观。

    TiDB 在 360 云平台的采取状态

    对于这一崭新的必发娱乐登录,咱们本着大胆用,不拘泥于传统的态势进行应用。

    咱们的 MySQL 如今也正在适配 8.0 本子,MongoDB、ES 也都是时候关注着新版本情况来评估是否确切云平台。

    故此 TiDB 的上点也是副离线工作→竞争性业务→基本业务来过渡的。

    历经大量之统考、也参考了另外企业的采取状态,咱们计划将 TiDB 步入 360 HULK 云平台,并准备后期对他不断完善在云平台中的功能,对全公司工作线开放使用。

    研制化开发一些 MySQL 已经具备的,例如 SQL 审查、慢查统计、冗余索引检测、自增索引阈值等各个基础作用等等。

    虽然在采取过程中遇到了部分小问题,例如索引的挑选、数的调优,因为一些配置导致的性质抖动,但都得到了 PingCAP 同学快速的呼唤和回答,这对我们推进 TiDB 有重点的协助。

    一键迁移工具 DM 年货分享

    DM 采用经验如下:

    ①权限

    官网手册上只说明需要如下权限:

    TiDB Lightning 要求以下权限:

  • SELECT
  • UPDATE
  • ALTER
  • CREATE
  • DROP
  • 存储断点的必发娱乐登录额外需要以下权限:

  • INSERT
  • DELETE
  • 但实测过程中发现还要求如下权限:

  • 上风 (REPLICATION SLAVE 权限必须具备,要不增量同步会 access deny)。
  • 上游 (不加 super 会导致 checksum table 无法推行)。
  • ②TiKV Region Score

    PD 监督中 -Statistics-balance 官方,有 Store-region-score 监督项,此地记录的是各国节点的 Score 得分,正常情况下,咱们盼望的结果是得分接近的,这表明无需进行 Region 科普迁移。

    ③PD 安排原理

    Region 负载均衡调度主要依托 balance-leader 和 balance-region 两个调度器。

    两岸的布置目标是将 Region 户均地分散在集群中的所有 Store 上,但它们各有侧重:

  • balance-leader 关怀 Region 的 Leader,目的是分散处理客户端请求的压力。
  • balance-region 关怀 Region 的各国 Peer,目的是分散储存的压力,同时避免出现爆盘等景象。
  • 咱们这里根本关注的是 balance-region,顶他出现不均的时节,咱们可以直接在监控中看到类似下图所示:

    安排期间,不可避免的会出现 IO 争用、光盘的 lantency,都会出现不同档次的上涨,副工作上的举报看,就会出现积压,呼唤不及时等等。而当 Region Balance 形成后, Duration 等城市恢复健康水平。

    故此,咱们要关心的中央有两线:

  • 如何控制或减少 Region Balance 科普迁移时对业务的影响;
  • 如何提前规避因磁盘导致的大范围 Region Balance。
  • 对于重大线,咱们迁移的时节是有数可以操纵的。此地无论是磁盘空间阈值,还是 Region Balance 安排速度,或者 Drop 汪洋表后调整空 Region Merge 的进度,其实都是可以通过 pd-ctl 的 config set 命令来实时调节。

    例如:

  • high-space-ratio 0.7 #安装空间充裕阈值为 0.7。顶重点的蓝天占用比例小于指定值时,PD 安排时会忽略剩余空间这个指标,重点针对现实数据量进行均衡。
  • region-schedule-limit 8 #最多同时开展 8 个 Region 安排。其一值主要影响 Region Balance 的进度,值越大调度得越快,安装为 0 则关闭调度。Region 安排的开支较大,故此这个值不宜调得太大。也得以通过压缩该值来限制调度region对集群产生之影响。
  • merge-schedule-limit 12 #最多同时开展 12 个 merge 安排。安装为 0 则关闭 Region Merge。Merge 安排的开支较大,故此这个值不宜调得过大。
  • leader-schedule-limit 8 #最多同时开展 8 个 leader 安排。其一值主要影响 Leader Balance 的进度,值越大调度得越快,安装为 0 则关闭调度。Leader 安排的开支较小,要求的时节可以方便调大。
  • max-merge-region-keys 50000 #安装 Region Merge 的 keyCount 上限为 50k。顶 Region KeyCount 大于指定值时 PD 不会将他与相邻之 Region 统一。
  • max-merge-region-size 16 #安装 Region Merge 的 size 上限为 16M。顶 Region Size 大于指定值时 PD 不会将他与相邻之 Region 统一。安装为 0 表示不起来 Region Merge 效益。
  • TIPS:了解了企图和规律,上述参数都得以根据需要自行控制。

    例如当我们在 Drop 汪洋之外表后,会产生许多之空 Region。在 Region 多少较多的情况下,Raftstore 要求花费一些时间去处理大量 Region 的心跳,故而带来一些延迟,导致某些读写请求得不到及时处理。

    如果读写压力较大,Raftstore 点程的 CPU 汇率容易达到瓶颈,导致延迟进一步增长,进而影响性能表现。

    故此我们会希望尽快的开展 Region Merge,来避免过多之 Region 对集群造成性能损耗时,咱们可以同时调小 max-merge-region-keys、max-merge-region-size,来让他更快的接触 Merge 借鉴,同时调大 merge-schedule-limit 增长并发度。

    例如当我们发现某台 KV 光盘空间剩余 40% 起来大量调度时,咱们可以将 high-space-ratio 调整到 0.7,以临时避免调度对工作产生之影响。

    咱们也得以操纵调度的并发度,来减少对工作产生之影响,实测这都是立竿见影的底数,大家如果遇到这些题材可供参考。

    对于第二线,尤其是采取 DM 期间,名将 DM-worker 和 TiKV 混合部署之情况下,要小心清理全量备份留下的公文和 Relaylog。

    默认调度策略是当磁盘剩余的得力空间不足 40%,处于中间态时则同时考虑数据量和剩余空间两个因素做加权和当作得分,顶得分出现比较大的差别时,就会开始调度。

    故此 DM 导入完成后,要记得删除全量备份。就是 dumped_data.task_xxx 文件夹,其一全量备份一般都会比较大,如果 dm-worker 和 TiKV 混部,就会出现某个 TiKV 重点磁盘已使用率高于其它。

    这会儿 PD 的 store region score 就会相比其他节点出现异常,引起性能抖动和 Duration 升高。

    一直等待其追上下,才会像下图这样:

    此刻,balancer 已达平衡状态:

    Duration 恢复健康水平,如下图 16:54 成分时的状况:

    QPS 也不再积压,恢复健康水平:

    关于 relay-log,默认是不清理的,就和 MySQL 的 expire_logs_days 一样,这块可以通过 dm-worker 的配置文件来开展布局。

    例如将 Expires 安排为 7,代表 7 天后删除:

          
    1. [purge] 
    2. interval = 3600 
    3. expires = 7 
    4. remain-space = 15 

    Expires 来支配保留天数。默认 expires=0,即没有过期时间,而 remain-space=15 意思是当磁盘只剩于 15G 的时节开始尝试清理,这种情景我们极少会遇到,故此这个清理方式其实基本上是用不到的。

    故此建议有需求删除过期 relay-log 的伴儿,直接配置 Expires 保留天数就足以了。

    DM 导入完成后,有道是提供是否在成功后自动删除全备文件的挑选,可以默认不删,由使用者决定是否删除。

    副使用者角度来说,全量备份目录无论是全量一次性导入还是 all 客流同步,持续都不会再采取到。

    如果 dm-worker 和 TiKV 混部,会导致全备文件占据大量光盘空间,引起 TiKV Region 评分出现异常,导致性能下降,已转化为 PRM 产品需求。

    ④关于 DM 采用期间出现数量丢失的题材

    在最初还没有 dm-portal 电气化生成 task 时,咱们都是自动编写 DM 的 task 同步文件。新兴有了 dm-portal 电气化生成工具,只要图形页面点点点就足以了。

    但该工具目前有一度问题是,没有全库正则匹配,即便你只勾选一个库,她底层是公认把每张表都送你配置一遍。

    这就会出现当上层 MySQL 新创建某张表的时节,上游会把忽视掉,例如当你利用改表工具 gh-ost 或者 pt-online-schema-change,你的暂时表都会把当做为不在白名单内而把忽视,其一题目使用者需要注意。

    咱们也已经申报给了合法。前途不久之本子估计就足以修复。

          
    1. ["skip event"] [task=task_20357] [unit="binlog replication"] [event=query] [statement="ALTER TABLE `360`.`_data_201910_gho` ADD COLUMN `raw_url_md5` CHAR(32) NOT NULL DEFAULT '' COMMENT 'raw_url md5'"
    2. ["skip event"] [task=task_20357] [unit="binlog replication"] [event=query] [statement="ALTER TABLE `360`.`_data_201910_gho` ADD INDEX `idx_rawurl_md5`(`raw_url_md5`)"] [schema=flow] 
    3. ["skip event"] [task=task_20357] [unit="binlog replication"] [event=query] [statement="ALTER TABLE `360`.`_data_201910_gho` DROP INDEX `idx_raw_url`"] [schema=flow] 

    此地日志可以看出 event 把 skip 了。

    ⑤关于 DM 采用期间偶发性 1062 东道主键冲突的题材

    query-error task 能收看具体的报错信息,上游看都没有该值:

          
    1. mysql> select * from client where clientid='82b51e6f6eb64955487f978dd94a2c81e492f6170xxxxxxxxxxxxxxxxxxxxxxxxx'
    2. Empty set (0.00 sec) 

    再扮上游看,结果发现也没有值,工作逻辑应该是新兴 delete 了:

          
    1. mysql> select * from client where clientid='82b51e6f6eb64955487f978dd94a2c81e492f6170xxxxxxxxxxxxxxxxxxxxxxxxx'
    2. Empty set (0.00 sec) 

    因为上游也没有值,扮演上游看 Binlog 此后分析如下:

    是先写入,再删除,故此上游没值是可以预料的,但是下游还没有同步到这块,此刻也是没有值的,不应当存在 1062 的题材。

    顶集群有大范围 kv:1062 报错时,或者集群写入压力大时,DM 副结果看无法保证 Binlog 的平稳落盘,需确认 DM能不能保证 LVS 从的多个 TiDB Binlog 的每一个 Event 是一成不变执行的。

    只从现象看,只要集群没有恢宏之 1062 报错,PD 相关的监察值都比较低,DM 也不会出现任何同步报错,反之就出现。

    副 Binlog 瞧就像是着重枝 Insert了,还没赶趟 Delete,直接 Insert 产生之报错,但报错后那个 Delete 的也到位了,故此这时刻我再怎么快也快不到毫秒级,上游看不到所有记录。

    消灭之措施是将 1062 汪洋冲突的工作拆分出集群,或 DM 直接写 TiDB 的真正 IP 而不是 LVS。

    ⑥DM 同步突出

    有工作反馈 Drop 成分区和 Drop 趟时出现同步突出。补下分区表相关的统考的结果,DM 更多的力不从心拆分的状况还是在 Drop 这块,一般说来的 add,modify 没问题的。

    一次删除多个分区的借鉴则会报错:

          
    1. alter table dsp_group_media_report drop partition p202006 ,p202007 ; 

    Drop 含有索引的进操作会报错:

          
    1. Alter table dsp_group drop column test_column; 

    40 京表添加 DDL 补充索引导致的 Duration 升高:

    固定到是:

          
    1. mysql> show global variables like 'tidb_ddl_reorg_worker_cnt'
    2. +---------------------------+-------+ 
    3. | Variable_name             | Value | 
    4. +---------------------------+-------+ 
    5. | tidb_ddl_reorg_worker_cnt | 16    | 
    6. +---------------------------+-------+ 
    7. 1 row in set (0.11 sec) 
    8.  
    9. mysql> show global variables like 'tidb_ddl_reorg_batch_size'
    10. +---------------------------+-------+ 
    11. | Variable_name             | Value | 
    12. +---------------------------+-------+ 
    13. | tidb_ddl_reorg_batch_size | 1024  | 
    14. +---------------------------+-------+ 

    上述两个参数对已有非 pcie 集群压力比较大导致。穿过 set global 调整(3.0.3 此后,默认从 256 涨到了 1000 和 16):

          
    1. tidb_ddl_reorg_batch_size 1000-256 
    2. tidb_ddl_reorg_worker_cnt 16-4 

    同时,增长 Compaction 相关:

          
    1. max-background-jobs: 8-10-12 
    2. max-sub-compactions: 1-2-4 
    3. defaultcf.compression-per-level: ["lz4""lz4""lz4""lz4""lz4""zstd""zstd"
    4. writecf.compression-per-level: ["lz4""lz4""lz4""lz4""lz4""zstd""zstd"

    末了的僵化结果是,QPS 稳定在 3K 控制:

    ⑦沉默寡言 Region 起来

    在现实状况中,读写请求并不会均匀分布到每个 Region 上,而是集中在个别之 Region 上。

    这就是说可以尽量减少暂时空闲的 Region 的信息数量,这也就是 Hibernate Region 的效应。

    产业化必要时也好进行 raft-base-tick,即不驱动空闲 Region 的 Raft 状态机,这就是说就不会触发这些 Region 的 Raft 产生心跳信息,大幅度地减少了 Raftstore 的上班担负。

    截至 TiDB v3.0.5,Hibernate Region 仍是一番实验功能,在 TiKV master 分支上已经默认开启。可根据现实状况和需要来开启该功能。

    数如下:

          
    1. raftstore.hibernate-regions: true 

    ⑧DM 导入期间 Duration 升高

    在 DM 导入集群期间,活生生会因为写热点的题材导致集群整体 Duration 更高,因为 IO 争用会更鲜明。此地其实也是可以通过一些指数来让集群运行的更快的。

    如下参数从原值调到-新值:

          
    1. raftstore: 
    2. apply-pool-size: 3-4 
    3. store-pool-size: 3-4 
    4.  
    5. storage: 
    6. scheduler-worker-pool-size: 4-6 
    7.  
    8. server: 
    9. grpc-concurrency: 4-6 
    10.  
    11. rocksdb: 
    12. max-background-jobs: 8-10 
    13. max-sub-compactions: 1-2 

    可以看出效果如下:QPS 不再抖动,Duration 也恢复到正常的档次。

    ⑨DM Debug 相关

    DM 还有个注意点就是 dm-worker.toml 配置文件里之安排 log-level=“debug” 是不生效的,起先的时节默认有个 -L=info 慎选,会覆盖掉配置文件里之,默认 -L 优先级高于配置文件,事在人为排查时自行启动。

    具体地说当需要对 dm-worker 起来 debug 分立式,要人工拉起进程并指定 -L 慎选=debug。

    ⑩TiDB load data 速度不理想

    TiDB 脚下 load data 的导入速度不及 MySQL,如果依赖 load data 的话,这块可以调优一下指数。

    咱们的面貌是 TiKV 上没有明确的瓶颈,重点慢在了 scheduler latch wait duration,可以调下参数看看:

          
    1. storage: 
    2. scheduler-concurrency: 204800000 
    3.  
    4. raftstore: 
    5. raft-max-inflight-msgs: 4096 

    调优完成后是有提升,但提升不大,咱们得知新版本的 TiDB 在 Load data 这块又有速度提升,比起期待新版本。

    其它干货打包分享

    ①TiDB 列数超限

    MySQL 是 1024,TiDB 脚下限制是 512 趟。如果你的外表有特别多之进,这就是说这块要提前注意下是不是可以拆分出去。

    ②GC can not work

    GC 的多寡包括两部分,一些是 DML 和 DDL ,DDL 的 GC 的目标信息包含在 mysql.gc_delete_range 和 mysql.gc_delete_range_done ,离别记录的是待 GC 的目标以及已经 GC 的目标。mysql.gc_delete_range_done表面里面没有多少不代表 GC 独特。

    法定建议更换规则:

          
    1. sum(increase(tikv_gcworker_gc_tasks_vec{task="gc"}[1d])) 

    ③TiDB or 谱优化

    在 TiDB 官方,如下查询是不能用到索引的

          
    1. select * from manual_domain where host_md5  = '55fbea39965484a61xxxxxxxxxx'  or domain_md5 = '55fbea39965484a61xxxxxxxxxx'

    MySQL 官方采用了 index_merge,TiDB 精算 4.0 支持,可以先用 union all 来处理这种 a or b。

    ④Coprocessor CPU 消耗过大

    工作反馈查询变慢,意识是另外一个作业全表扫 insert into select 导数据导致的。

    扮演 CPU 占用率高的这台机械上寻找对应的 log,关键字 slow,意识如下情况:

          
    1. [2019/09/18 10:04:37.339 +08:00] [INFO] [tracker.rs:150] [slow-query] [internal_key_skipped_count=46649] [internal_delete_skipped_count=0] [block_cache_hit_count=1596] [block_read_count=9] [block_read_byte=31933] [scan_first_range="Some(start: 7480000000000002285F72800000000021E9BD end: 7480000000000002285F72800000000024199A)"] [scan_ranges=1] [scan_iter_processed=46650] [scan_iter_ops=46652] [scan_is_desc=false] [tag=select] [table_id=552] [txn_start_ts=411244239493267464] [wait_time=2ms] [total_process_time=1.41s] [peer_id=ipv4:192.168.1.248:45686] [region_id=835437] 

    根据 table_id 扮演通过 information_schema.tables 表面查一下,可以通过上述措施来定位到是什么张表导致的题材。

    TiDB enum 导致的性质问题:

  • enum 在 TiDB 3.0.2 拓展 where 谱查找是,意识不能从推到 TiKV。法定说4.0GA 修复。临时办法是修改到其它品种。
  • enum modify 为 tinyint 意识内容出现变化,原来的’'成为了 default 值,‘1’ 成为了 2,经测试 varchar 正常,故此不要尝试去改变 DM 备份出来的 Schema 文件来促成表结构改变,有道是从上游 MySQL 消灭。
  • ⑤分区表元数据无法获取

    没有视图可以查询当前已建分区信息。在 TiDB 官方目前没有视图支持查询分区表已建分区信息,这就是说用户那边没有艺术直观的论断当前已建的基站,以及当前是否需要及时的补给新分区。脚下已转化为 PRM 产品需求,相信新版本不旧会实现。

    分区表 - 局部分区 - limit 未从推:分区表出现 limit 未从推的场面,表面 content_info_p 其中只有分区 p201911 有多少。该问题已在 3.0.6 本子修复。

    mysql.tidb 表面权限异常:采用 use db_name 或者 mysql 客户端指定 DB name 此后,可以对该表进行查询或更新操作。精算 3.1 本子修复。

    事物的限制:单个事物的 SQL statement 不超过 5000(stmt-count-limit 数可调);每个键值对不超过 6M;键值对的总和不超过 300000;键值对的总大小不超过 100M。

    注:键值对是指一张表里有 2 个目录,这就是说一共就是数值 +2 个目录,总计 3 个键值对,这就是说每个键值对的总是不能超过 30 万/3=10 万。

    一行数据会映射为一个 KV entry,每多一个索引,也会增加一个 KV entry,故此这个限制反映在 SQL 规模是:总的行数*(1+目录个数)<30w。

    法定提供内部 batch 的主意,来绕过大业务的限制,离别由三个参数来支配:

  • tidb_batch_insert
  • tidb_batch_delete
  • tidb_dml_batch_size
  • 写热点的拍卖:如果可以去掉 MySQL 自增主键,就足以通过建表时指定 SHARD_ROW_ID_BITS、PRE_SPLIT_REGION 来促成预切分,避免单调自增引发的只往某个 KV 上写数据引起的紧俏问题。

    详情可参照官网 TiDB 专用系统容量和语法中 SHARD_ROW_ID_BITS 的介绍。

    ⑥TiDB 监督和 DM 监督 Ansible 布局数据冲突

    这块可以通过将 TiDB 和 DM 监督部署到不同之机械上来绕过解决,否则就会出现通过 Ansible 安装后,ansible-playbook rolling_update_monitor.yml --tags=prometheus 时,二者只有一度是健康的。

    光盘已利用不建议超过 50%:数量量太多 LSM 过大, compaction 本会很高,并且内存命中率下降,同时单机恢复时间很长,50% 控制最好,汇率太高,如果突然写入爆增,region 来不及调度会写满磁盘,有高风险。

    故此建议 SSD 无需使用超过 2T 的,利用更多的机械会有更好的性质。

    ⑦Mydumper 导致的内存和网卡打满

    在采取 Mydumper 备份大时,会打满 TiDB 网卡,同时会消耗 TiDB、TiKV 更多的内存。

          
    1. 【TiDB ERR】[emergency]TiDB_schema_error:192.168.1.1:10080,[add_dba_mysql]【360】 
    2. 【TiDB ERR】[critical]NODE_memory_used_more_than_80%:192.168.1.2:9100,[add_dba_mysql]【360】 

    扮演抓取慢日志会见到如下内容:

          
    1. grep Query_time tidb_slow_query-2019-12-24T04-53-14.111.log|awk -F : '$2>10' 
    2. Time: 2019-12-24T03:18:49.685904971+08:00 
    3. # Txn_start_ts: 413433784152621060 
    4. User: backup@192.168.1.3 
    5. # Conn_ID: 4803611 
    6. # Query_time: 4002.295099802 
    7. SELECT /*!40001 SQL_NO_CACHE */ * FROM `360`.`t_d` ; 

    希望后续的本子物理备份,逻辑备份看起来目前是可以备份,但会比较消耗资源,同时恢复时间也会更久。

    展望

    副 TiDB 2.x 起来我们就已经初步进行测试了,末了摘取的本子是 3.0.2,持续升级到 3.0.5。

    上述文章总结和局部案例希望能够帮助到已利用或打算使用 TiDB 的爱人。

    360 云平台 DBA 团组织也准备将 TiDB 推上 360 HULK 云平台,为 360 集团更多的工作线提供丰富多彩和稳定性可靠的必发娱乐登录服务。

    在此间首先要感谢 PingCAP 同学及时的技艺支持,赞助我们尽快的消灭了部分艺术问题。

    同时,我自己也通读完了 TiDB 的合法手册。副 Ansible 布局、批办制部署、升级、DM、Lighting、Pump、Drainer、调优、彩排障、搬迁、备份,这一路打怪下来,切身感受到了 TiDB 越来越好的经过。

    我深信不疑未来随着 3.1 和 4.0 本子的生产,有更多人参加使用 TiDB 的这个师中来。

    副工作给咱们的举报也是对 TiDB 的采取状态表示满意,咱们相信,TiDB 会在大家共同之艰苦奋斗下,越来越好。

    【51CTO原创稿件,合作站点转载请注明原文作者和出处为51CTO.com】

    【编纂推荐】

    1. Linux运维:高可用MySQL解决方案概述
    2. 如何精心筹划必发娱乐登录向云平台的搬迁
    3. MySQL 的 MRR 到底是什么?
    4. MySQL:互联网公司合同分库分表方案汇总
    5. 阿里云面试官:如果是MySQL引起的CPU消耗过大,你会如何优化?
    【义务编辑: 武晓燕 TEL:(010)68476606】

    点赞 0
  • MySQL  搬迁  TiDB
  • 分享:
    大家都在看
    猜你喜欢
  • 订阅专栏+更多

    网络排障一点通

    网络排障一点通

    网络排障及优化调整案例
    共20章 | 捷哥CCIE

    292人口订阅学习

    VMware NSX 入夜到实战

    VMware NSX 入夜到实战

    网络虚拟化革命性技术
    共16章 | Cloud袁

    210人口订阅学习

    信息队列Kafka运维实践攻略

    信息队列Kafka运维实践攻略

    入夜级消息队列
    共3章 | 独行侠梦

    112人口订阅学习

    订阅51CTO邮刊

    点击这里查看样刊

    订阅51CTO邮刊

    51CTO劳务号

    51CTO官微

    
       
       
        



      &lt;object id="d2dd1756"&gt;&lt;/object&gt;