熬了一整夜去弄Mysql主从，终于在凌晨三点之际，瞧见显示为Yes，还有也呈现为Yes……那种感受实在没得说，为此推掉了两瓶红牛用来庆祝一番。
到底要配哪几个文件？
就f而言，存在着总共三个核心参数，在此不多作赘述：其一，-id这个参数，主库与从库所设置的值必须是不一样的，这一点想必大家都是清楚知晓的；其二，log-bin=mysql-bin，此设置意味着开启；其三，=ROW。实际上，对于ROW这种格式，最初的时候我自己也是不太能够理解为何要进行这样的推荐，一直到后来某次出现了格式引发复制错位的情况……算了，关于此后续再作指责吧。
这句在主库里跑： USER ”@’%’ BY ‘xxx’;接着授权 SLAVE。不要用root，因为安全检查与的组合拳会让你哭。
主库怎么看日志点？
SHOW ;
谨记File跟这两列所对应的值，要记住锁定数据库即用FLUSH WITH READ LOCK来制作备份快照，不要询问我为何要去提醒你，我曾经忘掉了这操作步骤直接进行配置，导致从库同步数据出现大量的错位情况，修复到令人作呕。
从库丢数据怎么破？
将主库备份进行导入，要拿到或者文件，在从库上执行恢复操作，，不然会默认从当前空数据开始同步，如此一来从库少的库就不会同步新的数据。
配置从库连接
在MySQL 8.0.23往后，要使用 TO ，而在旧版本的时候，则需使用 TO。
TO ='主库IP', ='', ='密码', ='主库的File值', =主库的值;
跟着8.0习惯来，然后打出START ; ，再打出SHOW G查一查两个是不是都为Yes。我原来使用旧命令START SLAVE发现也能运行，不过后来版本升级出现。
GTID模式要不要开？
开启它，真的很香！由源标识与事务标识构成的GTID编号。再也不用去记住那几十个文件里令人厌恶的位点了。当发生故障切换之际，重新执行 TO =’新主’, =1; 便能够直接接续之前的操作。不足之处在于：跨越不同版本极易遭遇问题。
怎么只同步指定库？
往从库的f里添加-do-db等于你所期望的库，或者动态地更改 为 ()，留意，参数绝对不能放错位置，放错会致使其他库数据不更新。更让人觉得坑的是，要是主从库借助表名或者函数调用这种方式进行跨库操作，那样的话，这种过滤规则有可能会出现异常情况，复制的逻辑会让你根本搞不清楚状况。我就曾经遇到过一回，从库怎么都莫名其妙地少了一张表的数据，费了好大劲翻了半天的log才查明原来是和ble的交互规则在捣乱，而后去查看文档才知道副本先是按照库级进行过滤，接着再按照表级进行过滤——真是让人头疼。
异步还是半同步？
设置为默认异步，主事务提交之后便不再理会从库这种模式性能是最高的。半同步的情况下需要等待至少一个从库进行确认——这里所说的一个从库确认的前提是unt设置为1。假定存在一半是同步一半是异步这样的情况呢？实际上这是需要依据业务来进行判断的——对于交易类业务提议采用半同步以确保数据部丢失，而日志类业务使用异步就可以了。然而半同步存在超时机制，要是等不到响应就会退化为异步模式。
1062、1032这两个鬼东西怎么搞？
1062这个主键冲突，以及1032这个找不到数据情况，我提出建议，首先去查看SHOW G的，然后再去查看具体的文件中哪句出现了问题。GTID模式当中，要是非得跳过这一条，那就运用SET = ‘xxxx’;，接着实施BEGIN;，随后执行;，再之后设置SET = ”;，最后启动START ;。不走GTID模式，运用SET ER = 1;径直跳过一个事件，当然，最好去做数据修复，别依靠跳过。
实际上，问题的根源大多在于主从并非保持一致，大业务事务致使从库难以跟上主库的节奏。把小业务事务进行分拆，主库在增删改操作方面减少大业务事务的涉及，如此一来，从库的延迟状况便会得到改善，是的。
延迟怎么办？
开启并行复制，设置rs为4，你会发觉r从几百秒降至十几秒。要是使用MySQL 8.0另有个并行功能，那就更厉害了。
数据不一致怎么对账修复？
pt – table – 去进行校验，而后运用pt – table – sync来修复，这点是必须要在主库那里执行的，而且得先通过–dry – run来验证。要是直接进行–，万一没有确认主库是唯一的写入源头，那样它所生成的反向修复语句会将你的数据弄乱……所以千万别相信网上那些偷懒的教程说执行一下就万事大吉了。我也曾踩过这般的坑，即pt – table – sync默认仅仅输出SQL语句，若不加–，你便会认为已然修好，然而结果数据依旧是错误的。并且，你所要修复的表必定得拥有主键或者唯一索引，不然在修复之际无法进行分块，进而会报错。
还有一个步骤，即等到修复完成之后，要将表里面的数据与主库进行操作，以此来确认二者是一致的。最后，千万不要忘记去验证pt-table-运行所得到的结果字段，需要特别留意字符集，要是主从的se以及并不一致，那么比对的时候就会出现错误。这个容易出错的地方值得专门记录下来。
为什么修改了配置不生效？
的确，好多时候我自己也曾有过忘掉重启MySQL服务的情况。另外存在一些问题：其一，主从库所设定的-id出现冲突，查看一下是否默认是1；其二，主库的路径没有写入权限或者路径并不存在；其三，将3306端口给拦截了。
多源复制的特殊点
一台从库同时对多个主库进行复制，这就要求得针对每个主库单独去配置一个复制通道，而且在 TO语句当中要添加上FOR 。我仅仅只是在测试环境进行过相关操作，然而实际上它对于实现数据聚合而言的确是极为便利的。
夜晚两点时分，mysql slave老是报1032，我添加上了参数，然而并未解决问题，后来发觉人家从库存在一个格式与主库不一致的情况。实际上能够set = ROW，接着重启同步，反正从库在这个时候闪一下才会生效。不重启可不可以将会话级别下的改过来呢？但实际还是要从库改。这种细碎状况。
不管怎样，当终于成功之时，已经是凌晨三点多，我对着e：0发了好一阵呆，差点呐还忘掉了截图这回事，心里想着要发给兄弟们瞧一瞧。
的确，始终牢记 SHOW G 的那几个关键重要字段（, , ）时常进行核查，这相较于任何方面的配置而言均关键至关重要 ，在 Git 仓库当中务必存放好 f 的备份以及初始化脚本，如此一来下一次便不会再度经历通宵那般的状况 ，由于确实不会再有意愿重新再来一回 ，切莫像我这般工作奋斗直至凌晨。
