建议使用以下浏览器,以获得最佳体验。 IE 9.0+以上版本 Chrome 31+ 谷歌浏览器 Firefox 30+ 火狐浏览器
请选择 进入手机版 | 继续访问电脑版
设置昵称

在此一键设置昵称,即可参与社区互动!

确定
我再想想
选择版块

小路~

发帖: 26粉丝: 7

级别 : 版主

Rank: 7Rank: 7Rank: 7

发消息 + 关注

发表于2018-7-18 15:51:12 6363 31 楼主 显示全部楼层
[活动已结束] 【评论有奖】数据高可用备份教程开放,无效“全额退款”

题头.png

看完本帖,你将收获

华为云技术专家教你的数据备份永不出错的诀窍

和萌宠加湿器一个

                                           

最终12.jpg

生产环境的数据库多数是带备份的,至少是一主一备,目的是当主机出现宕机但是又不能很快恢复时,把业务切换到备机上,快速恢复业务, 但是备机也可能会故障,有时候还需要基于当前的数据做一份新的数据库出来,此时怎么做? 是不是还得一个冷备份呢?所以基本的数据库架构很多是这样的:

2_meitu_5.jpg

数据库基本架构


最初我们做RDS for MySQL 备份也是基于这样的模型,但不同的是,我们引入了对象存储系统(Object Storage)。因为实例较多,发生切换时不能靠人工处理,因此引入了高可用系统(High Available)。针对备份,我们也抽象出一个独立系统,用来处理复杂的备份和还原过程,称之为备份恢复系统(Backup and Restore)。最终的框架图如下:

3_meitu_4.jpg

高可用备份框架图


优化:
触发备份时,可能会导致主机资源被占用,例如压缩时占用 CPU 资源,上传会占用IO,所以业界RDS for MySQL都会在备机上做备份,但是仅仅是换个主机这么简单吗? 下面重点说说我们在此过程中踩过的一个坑吧!

敲黑板划重点:


基于备机备份第1个带来的问题我们要正视,那就是可能的延迟,整体上延迟时间为:

OBS上的数据时间 晚于 备机的数据时间 晚于 主机的数据时间

即:OBS上的数据可能晚于备机的数据,而后者又晚于主机的数据。
这个延迟会带来其它问题,我们在做高可用和可靠性混合测试时碰到过。

假设A的uuid为A,B的uuid为B,具体操作步骤和数据如下:

配图1_meitu_1.jpg




操作

主机A

主机B

OBS

1. 持续写入数据

GTID SET A:1-900

GTID SET A:1-900

GTID SET A:1-900

2. 断开AB之间网络,不触发主备倒换

GTID SET A:1-2000

GTID SET A:1-900

GTID SET A:1-900

3. 停止写入,恢复网络

GTID SET A: 1-2000

GTID SET A: 1-1200

还未到增量备份时间,GTID   SET A:1-900

4. 把A关机

不可用

GTID SET A: 1-1200

还未到增量备份时间,GTID   SET A:1-900

5. HA触发主备切换

不可用

切换为新主机

还未到增量备份时间,GTID   SET A:1-900

6. 新主写入数据,即B写入数据

不可用

GTID SET A:1200,B:1-100

还未到增量备份时间,GTID   SET A:1-900

7. 启动旧主机
场景1:触发A主机重建,即基于OBS的数据做PITR还原

GTID SET A:1-900

GTID SET A: 1-1200,B:1-100

GTID SET A:1-900,或者A:   1-1200,B:1-100,具体取决于时间

8. 重新建立主备复制关系

此时GTID SET会是1-1200,B:1-100 ?
真实结果是:
A: 1-900,B:1-100




看下我们测试的结果:

5_meitu_8.jpg

图1 新备机

6_meitu_7.jpg

图2 新主机


大家注意,如果这部分数据没有同步过来其实是一个非常危险的动作。因为此时主备复制关系都是正常的,所以很容易被忽略。而且由于这样的延迟关系,该场景下的问题的发生是一个大概率事件。

很显现,MySQL并没有按照大家想象中那样去做。很多 DBA 都做过这样的实验,把已经从主机同步过来的数据在备机删除掉,然后设置已经执行的 GTID 为之前的值,数据会重新从主机同步过来,而且只认 GTID 不认内容,可是为什么现在就不行了呢?

在此过程中,我们进行了各种检查。先是验证是否备份出现问题,然后又验证是否还原步骤出现问题,然而都不是…… 总不能是数据库 A 通过识别 GTID 发现,有部分数据是以自己的 uuid 开头,所以才没有同步吧?

所以我们尝试修改了A主机的server-uuid为C,但并没有任何结果。这样的结果,一度让我的思路陷入僵局,感觉大脑中的主备复制知识要被刷新了。打开解析后的binlog,看到 binlog 中使用的是 server ID,我想mysql是不是通过server ID来识别呢?抱着病重乱投医的心态,我尝试修改了 server ID,结果却意外地成功了!于是我们又顺着这条线索,查看 MySQL 官方文档,发现一个不常用参数。

--replicate-same-server-id

Command-Line Format

--replicate-same-server-id

Permitted Values

Type

boolean

Default

FALSE

To be used on slave servers. Usually you should use the default setting of 0, to prevent infinite loops caused by circular replication. If set to 1, the slave does not skip events having its own server ID. Normally, this is useful only in rare configurations. The option cannot be set to 1 when  is enabled, which is the default.
By default, the slave I/O thread does not write binary log events to the relay log if they have the slave's server ID (this optimization helps save disk usage). If you want to use , be sure to start the slave with this option before you make the slave read its own events that you want the slave SQL thread to execute.
--log-slave-updates enables replication servers to be chained. For example, you might want to set up replication servers using this arrangement:
A -> B -> C
Here, A serves as the master for the slave B, and B serves as the master for the slave C. For this to work, B must be both a master and a slave. With binary logging and the
--log-slave-updates option enabled, which are the default settings, updates received from A are logged by B to its binary log, and can therefore be passed on to C.

大意是说:
为防止循环复制引起的无限循环,备机默认设置通常为0。一旦设置为1,备机会忽略那些同自己具有相同server ID的事件,所以会出现上面我们遇到的问题。

测试了一遍,是它!

又测试一遍,是它!

再测试一遍,还真是它!

本以为找到了救命的灵丹妙药,但接下来的问题还是让我们面面相觑。

官方文档写明
replicate-same-server-idlog-slave-updates 互斥关系,而log-slave-updates则是我们在备机做备份必须开启的参数,所以该参数我们不能设置为on,这就相当尴尬了……

目前这个问题只能规避,例如在每次恢复的时候,重新设置server ID 为一个不重复的值。而且 MySQL不推荐使用重复的 ID 值,也是为了防止出现无限循环复制。

此外,补充一个注意事项,就是在备机做运维动作时,对于修改数据、flush等这类会写bin-log 的操作时,一定要先执行 set sql_log_bin=0,否则你的每一笔操作,都会造成备机少同步一条数据。


文章到此结束,该问题的发现、重现、定位及解决,在追求数据的最大可靠性上,我们从不懈怠。



timg_meitu_1_meitu_13.jpg

评论有奖:

各位小可爱们需要回答的问题分别是:

1、  数据备份技能有没有get到呢?若没有,原因是?
2、  使用过华为云数据库的备份恢复功能吗?
3、  你们是怎么判断主备不一致的?
4、  主备机数据不一致的时候,你们有哪些运维动作?

评奖规则:在本帖留言区回复上述四个问题,对话题互动的优质用户进行评奖,其次是没有了解本教程,并给出改进意见的走心用户进行评奖。

活动时间2018年7月20日-7月27日

活动结束后,我们会抽取优质评论奖3名送出搭配小夜灯、小风扇三合一的萌宠加湿器


萌宠加湿器2_meitu_9.jpg

萌宠加湿器1_meitu_10.jpg


155444kssqnlafeiddqe9j.png

获奖名单

用户名奖品
xiao萌宠加湿器
meimeimei萌宠加湿器
蓝书签萌宠加湿器


恭喜以上获奖小伙伴,快将你们的邮寄地址私信给小编吧,否则视为自动放弃~

回复 举报
分享

分享文章到朋友圈

分享文章到微博

云里雾里

发帖: 12粉丝: 3

级别 : 注册会员

Rank: 2

发消息 + 关注

发表于2018-7-18 16:11:46 沙发 显示全部楼层

干货,顶一个!

点赞 回复 举报

aprioy

发帖: 99粉丝: 27

级别 : 版主

Rank: 7Rank: 7Rank: 7

发消息 + 关注

发表于2018-7-18 18:04:28 板凳 显示全部楼层

先顶后看。~

点赞 回复 举报

ecstatic

发帖: 10粉丝: 4

级别 : 版主

Rank: 7Rank: 7Rank: 7

发消息 + 关注

发表于2018-7-18 22:08:57 地板 显示全部楼层

对象存储系统(OBject Storage)   这块应该是Object Storage

点评

顶你: 5.0
顶你: 5
细心的小伙伴,已修改,为你点赞  发表于 2018-7-19 10:29
点赞 回复 举报

蝈蝈

发帖: 0粉丝: 0

级别 : 新手上路

Rank: 1

发消息 + 关注

发表于2018-7-19 19:05:08 5# 显示全部楼层

1、  内容详细,get到了

2、  用过

3、 接收的比较多关于主备延时的报警,导致主备延时的原因比较多,说下其中之一数据库中存在大量myisam表,在备份的时候导致slave 延迟。由于xtrabackup 工具备份到最后会执行flash tables with read lock ,对数据库进行锁表以便进行一致性备份,然后对于myisam表 锁,会阻碍salve_sql_thread 停滞运行进而导致hang

4、  该问题目前的比较好的解决方式是修改表结构为innodb存储引擎的表。


点评

顶你: 5.0
顶你: 5
给认真的小伙伴点赞!华为云数据库目前有免费领取的活动,也有包年58折的活动,有需要可以私信小编呢  发表于 2018-7-26 10:16
点赞1 回复 举报

W--wangzhi...

发帖: 4粉丝: 2

级别 : 版主

Rank: 7Rank: 7Rank: 7

发消息 + 关注

发表于2018-7-20 12:22:06 6# 显示全部楼层

1、数据备份技能有没有get到呢?若没有,原因是?

有get到

2、使用过华为云数据库的备份恢复功能吗?

还没有体验过

3、  你们是怎么判断主备不一致的?

认为主备数据不一致的常见原因有:

1 备库写数据   

2 执行non-deterministic query   

3 回滚掺杂事务表和非事务表的事务

4 binlog或者relay log数据损坏

4、主备机数据不一致的时候,你们有哪些运维动作? 

一般的处理方法是:

1 禁止修改备库数据

2 采用row-based replication

3 避免同一个事务中同时引用innodb和myisam表

4 开启binlog checksum


点评

顶你: 5.0
顶你: 5
给小伙伴点赞呐,另外华为云数据库有免费套餐可以领取哟,你想用的数据库都有呢,有需要可以私信小编,体验备份恢复功能哟  发表于 2018-7-26 10:11
点赞1 回复 举报

四年三班扛...

发帖: 9粉丝: 4

级别 : 版主

Rank: 7Rank: 7Rank: 7

发消息 + 关注

发表于2018-7-20 20:24:28 7# 显示全部楼层
1.技能get 2.没有使用过 3.定期使用类似于checksum的指令对主备库求值,再比较主备库得出的结果,如果结果不同,则主备库数据不一致 4.方法一:忽略错误后,继续同步 该方法适用于主从库数据相差不大,或者要求数据可以不完全统一的情况,数据要求不严格的情况 方式二:重新做主从,完全同步 该方法适用于主从库数据相差较大,或者要求数据完全统一的情况

点评

顶你: 5.0
顶你: 5
胖虎哥来啦,请上坐,悉听胖虎哥讲经验  发表于 2018-7-26 10:02
点赞1 回复 举报

蓝书签

发帖: 37粉丝: 9

级别 : 版主

Rank: 7Rank: 7Rank: 7

发消息 + 关注

发表于2018-7-21 09:49:26 8# 显示全部楼层

1、  数据备份技能有没有get到呢?若没有,原因是?

       get到了

2、  使用过华为云数据库的备份恢复功能吗?

       使用过,很方便,恢复和复制备份操作都很方便,下载如果是新手首次操作会有点不方便,但依照帮助中心教程来还是挺容易的。
3、  你们是怎么判断主备不一致的?

       通过一些命令操作可以判断出来

         1)MySQL checksum命令

       在执行checksum命令时,表会被加一个读锁(read lock),checksum table的原理是对表中的数据进行一行一行的较验和计算,因些对于大表,这是一个很耗时的过程。

如果对于myisam表,建表时加上CHECKSUM=1选项,那么在对这样的表进行checksum table时将会非常快

         2)mysqldiff

       mysqldiff该工具是官方mysql-utilities工具集的一个脚本,可以用来对比不同数据库之间的表结构,或者同个数据库间的表结构。

        3)mysqldbcompare

       mysqldiff该工具是官方mysql-utilities工具集的一个脚本,可以用来检查不同数据库之间的数据一致性,检查内容包括数据库字符集、表结构、数据内容,只要有一个不一样,则检查不通过。

        4)pt-table-checksum

       pt-table-checksum是在线的主从数据一致性检查工具,能够对大数据量的数据库进行高效的主从数据一致性检查,能够自动控制检查数据量的大小,避免对线上业务造成较大的影响。下面对展示该工具的常见几种用法,更多细节见pt-table-checksum官方帮助文档。

      

4、  主备机数据不一致的时候,你们有哪些运维动作?

       先pt-table-checksum校验数据一致性,接着修复不一致数据使用pt-table-sync 工具,使用pt-table-checksum工具的结果。不过这里还是有些坑。在修复之前最好把主mysql数据备份一下,因为会对主库有些写操作,有一点风险。最后修复数据,先修复一个不重要的表来实验下(主库操作),接着修复完成在执行一次check 主库操作,在从库mysql中检查下确认修复好了没问题后接着把其他表修复,然后检查下是否有问题就OK了。

点评

顶你: 5.0
顶你: 5
蓝蓝说的对,涨姿势~  发表于 2018-7-26 10:14
点赞1 回复 举报

ecstatic

发帖: 10粉丝: 4

级别 : 版主

Rank: 7Rank: 7Rank: 7

发消息 + 关注

发表于2018-7-21 11:13:03 9# 显示全部楼层

1、  数据备份技能有没有get到呢?若没有,原因是?

        get到了,小路老师辛苦了。
2、  使用过华为云数据库的备份恢复功能吗?

        没有使用过。使用过华为云的数据库迁移功能。
3、  你们是怎么判断主备不一致的?

        可定期调用pt-table-checksum进行主备数据校验,发现数据不一致则pt-table-sync进行恢复;                              可使用percona的pt-table-checksum

       原理
连接主库同时自动侦测并连接到所有备库,创建规则表
CREATE TABLE checksums (
   db             char(64)     NOT NULL,
   tbl            char(64)     NOT NULL,
   chunk          int          NOT NULL,
   chunk_time     float            NULL,
   chunk_index    varchar(200)     NULL,
   lower_boundary text             NULL,
   upper_boundary text             NULL,
   this_crc       char(40)     NOT NULL,
   this_cnt       int          NOT NULL,
   master_crc     char(40)         NULL,
   master_cnt     int              NULL,
   ts             timestamp    NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
   PRIMARY KEY (db, tbl, chunk),
   INDEX ts_db_tbl (ts, db, tbl)
) ENGINE=InnoDB;
一次只操作一个表,在主库执行基于statement的sql语句来生成主库数据块的checksum,把相同的sql语句传递到从库并计算相同数据块的checksum;
最后,比较主从库上相同数据块的checksum值,由此判断主从数据是否一致。也可手工查询

SELECT db, tbl, SUM(this_cnt) AS total_rows, COUNT(*) AS chunks
FROM checksums
WHERE (
 master_cnt <> this_cnt
 OR master_crc <> this_crc
 OR ISNULL(master_crc) <> ISNULL(this_crc))
GROUP BY db, tbl;

   如何计算checksum
   依据表的主键或唯一索引,将表划分为多个数据块,以数据块为单位进行计算;
   将块内数据行拼接起来,计算crc32的值,即为其checksum;
   每一次对chunk进行checksum后,pt工具都会对耗时进行统计分析,并智能调整下一个chunk的大小,避免chunk太大对造成影响,也要避免    太小而效率低下。
   一致性保证
   当pt工具在计算主库上某chunk的checksum时,主库可能还在更新,为保证chunk内部数据一致性,每计算一个chunk时加for update锁;
   并把计算结果保存到pt工具自建的结果表中(采用replace into select的方式),然后释放锁。该语句最终会传递到从库并执行相同的计算逻   辑。
   注意事项
1 —check-binlog-format是默认选项,建议不要关闭它。pt-table-checksum产生的sql语句要基于语句格式同步到从库,这是由它的实现原理决定的。
  但是在A-B-C的级联复制结构中,如果B是行格式的复制,那么B与C的数据一致性校验就没法做了。
 在A上设置该sql语句为语句级并不会把set这个动作记录到binlog中;

2 主从异构的情况下,checksum语句可能在从库上执行失败,即使是索引的不一致。
 例如sql语句中有force index某个索引,但是从库的表上没有这个索引,就会导致卡库。


        4、  主备机数据不一致的时候,你们有哪些运维动作?

        1 禁止修改备库数据
   2 采用row-based replication
   3 避免同一个事务中同时引用innodb和myisam表
   4 开启binlog checksum
   其中binlog checksum是5.6引入的新功能,由参数binlog-checksum控制(默认关闭);
   开启该功能后,master在写binlog event时同时记录checksum,slave读取relay log时对每个event执行checksum校验,如果失败则停止sql t   hread并报错。

   master-verify-checksum:默认关闭,开启后主库会对每个binlog event进行checksum验证,如果失败则停止写入并报错;
   slave_sql_verify_checksum:默认关闭,开启后备库读relay log时会对每个event进行checksum验证;

       如何同步主备库表     
   可使用pt-table-sync 
   原理
同pt-table-checksum一样,将表分成chunk并计算checksum,一旦发现主从上同样的chunk的checksum值不同,就深入到该chunk内部,
逐行比较并修复有问题的行。其计算逻辑描述如下:

1 对每一个从库,每一个表,循环进行如下校验和修复过程。
2 对每一个chunk,在校验时加上for update锁。一旦获得锁,就记录下当前主库的show master status值。
3 在从库上执行select master_pos_wait()函数,等待从库sql线程执行到show master status得到的位置。以保证主从上这个chunk的内容均不再改变。
4 对这个chunk执行checksum,然后与主库的checksum进行比较。
5 如果checksum相同,说明主从数据一致,就继续下一个chunk。
6 如果checksum不同,说明该chunk有不一致。深入chunk内部,逐行计算checksum并比较(单行的checksum的比较过程与chunk的比较过程一样)。
  如果发现某行不一致,则标记下来。继续检测剩余行,直到这个chunk结束。
7 对找到的主从不一致的行,采用replace into语句,在主库执行一遍以生成该行全量的binlog,并同步到从库,这会以主库数据为基准来修复从库;
 对于主库有的行而从库没有的行,采用replace在主库上**(必须不能是insert);
 对于从库有而主库没有的行,通过在主库执行delete来删除(pt-table-sync强烈建议所有的数据修复都只在主库进行,而不建议直接修改从库数据)。

  直到修复该chunk所有不一致的行。继续检查和修复下一个chunk。
8 直到这个从库上所有的表修复结束。开始修复下一个从库。
注意事项
1 pt-table-sync在修复过程中不能容忍从库延迟,这正好与pt-table-checksum相反。
 如果从库延迟太多,pt-table-sync会长期持有对chunk的for update锁,然后等待从库的master_pos_wait执行完毕或超时。
  从库延迟越大,等待过程就越长,主库加锁的时间就越长,对线上影响就越大。因此要严格设置max-lag。

2 对从库数据的修复通常是在主库执行sql来同步到从库。因此,在有多个从库时,修复某个从库的数据实际会把修复语句同步到所有从库。
  数据修复的代价取决于从库与主库不一致的程度,如果从库只有表结构,那么需要把主库的所有数据重新灌一遍,然后通过binlog同步并传递到所有从库。
  正确的做法是,先用pt-table-checksum校验一遍:如果不同步的很少,用pt-table-sync直接修复;否则,用备份先替换它,然后用pt-table

  PS:数据库只会增删改查。。。都是网上找到的,仅供大家参谋吧

点评

顶你: 5.0
顶你: 5
活捉一只大神级别的人物,大家快来围观呀  发表于 2018-7-26 09:53
点赞1 回复 举报

小修

发帖: 0粉丝: 2

级别 : 注册会员

Rank: 2

发消息 + 关注

发表于2018-7-22 12:41:11 10# 显示全部楼层


1、数据备份技能有没有get到呢?若没有,原因是?

没有get到,平时不是做运维,数据库相关的,更多的精力还是在开发和项目管理上。这个主要是讲解的原理性质的,这个还大概能明白。

但是如果不是经常跟这个打交道,或者对数据库主从备份有深入了解的话,可能不是特别明白。


2、使用过华为云数据库的备份恢复功能吗?

还没有体验过,不过刚去查询了解过了:华为云关系型数据库服务支持使用已有的自动和手动备份恢复实例数据,可选择恢复到当前实例或恢复到新实例,将实例恢复到备份被创建时的状态。

https://support.huaweicloud.com/usermanual-rds/zh-cn_topic_0037000196.html

账户余额大于等于0元,才可恢复到新实例。

3、  你们是怎么判断主备不一致的?

可定期调用pt-table-checksum进行主备数据校验,发现数据不一致则pt-table-sync进行恢复;                                                   

可使用percona的pt-table-checksum,http://nettedfish.sinaapp.com/blog/2013/06/04/check-replication-consistency-by-pt-table-checksum/

原理

连接主库同时自动侦测并连接到所有备库,创建规则表

CREATE TABLE checksums (

   db             char(64)     NOT NULL,

   tbl            char(64)     NOT NULL,

   chunk          int          NOT NULL,

   chunk_time     float            NULL,

   chunk_index    varchar(200)     NULL,

   lower_boundary text             NULL,

   upper_boundary text             NULL,

   this_crc       char(40)     NOT NULL,

   this_cnt       int          NOT NULL,

   master_crc     char(40)         NULL,

   master_cnt     int              NULL,

   ts             timestamp    NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,

   PRIMARY KEY (db, tbl, chunk),

   INDEX ts_db_tbl (ts, db, tbl)

) ENGINE=InnoDB;

一次只操作一个表,在主库执行基于statement的sql语句来生成主库数据块的checksum,把相同的sql语句传递到从库并计算相同数据块的checksum;

最后,比较主从库上相同数据块的checksum值,由此判断主从数据是否一致。也可手工查询

SELECT db, tbl, SUM(this_cnt) AS total_rows, COUNT(*) AS chunks

FROM checksums

WHERE (

 master_cnt <> this_cnt

 OR master_crc <> this_crc

 OR ISNULL(master_crc) <> ISNULL(this_crc))

GROUP BY db, tbl;

如何计算checksum

依据表的主键或唯一索引,将表划分为多个数据块,以数据块为单位进行计算;

将块内数据行拼接起来,计算crc32的值,即为其checksum;

每一次对chunk进行checksum后,pt工具都会对耗时进行统计分析,并智能调整下一个chunk的大小,避免chunk太大对造成影响,也要避免太小而效率低下。

一致性保证

当pt工具在计算主库上某chunk的checksum时,主库可能还在更新,为保证chunk内部数据一致性,每计算一个chunk时加for update锁;

并把计算结果保存到pt工具自建的结果表中(采用replace into select的方式),然后释放锁。该语句最终会传递到从库并执行相同的计算逻辑。

注意事项

1 —check-binlog-format是默认选项,建议不要关闭它。pt-table-checksum产生的sql语句要基于语句格式同步到从库,这是由它的实现原理决定的。

  但是在A-B-C的级联复制结构中,如果B是行格式的复制,那么B与C的数据一致性校验就没法做了。

 在A上设置该sql语句为语句级并不会把set这个动作记录到binlog中;

2 主从异构的情况下,checksum语句可能在从库上执行失败,即使是索引的不一致。

 例如sql语句中有force index某个索引,但是从库的表上没有这个索引,就会导致卡库。


4、主备机数据不一致的时候,你们有哪些运维动作? 

第一种:通过sql_slave_skip_counter跳过同步错误,适用于一般异常如**时主键冲突

第二种:重新做主从,然后使用change master指定同步位置,这种耗时长


总体的思路大概是这样:

1 从新从0开始同步,虽然对主库的使用没有影响,但是那么大的数据量,对性能,网络影响有点大,数据丢失的应该很少 

2 主库dump数据,锁库,然后同步,不好。 影响业务使用 

3 percona-toolkit 中的工具来校验和同步,从介绍上来看是符合现在的情况的,使用上还需要学习和认识才行。


点评

顶你: 5.0
顶你: 5
小编顿时成为了小修的迷妹,小修明明可以靠颜值吃饭非要靠才华  发表于 2018-7-26 09:52
点赞 回复 举报

游客

您需要登录后才可以回帖 登录 | 立即注册