集群迁移

最近受命将外部两个集群迁移到我们的环境，开始以为是简单的备份恢复，实际上道路还是比较曲折的，最终是搞定了

数据迁移，先看网络吧，首先确认不在公司内网中，公网也应该可以访问，只要能把备份集拿过来，然后实时获取 binlog就万事大吉了

由于时间不是很着急，心想搞个逻辑备份应该是兼容性最好最稳定的

那边提供了外部IP和port，开通的IP限制（深深的感觉到网络实战的匮乏，也许这就是大公司分工过细的弊端吧），我这边做了个实例的全备，不过恢复起来巨慢无比，检查了下是myisam的，至于慢的原因是不是myisam更新是表锁吗（暂时搞不清），第一次恢复失败

逻辑方式不行那就换物理，xtrabackup使用比较熟，可惜需求方那边不允许按照其他工具（一直表示怀疑），最终按照需求方的习惯，LVM快照+rsync，鉴于之间的网络问题，传了好几次才成功，挑出源配置文件中与myisam相关的参数替换了我们自己的配置文件，调整必要的目录结构，成功启动并很快同步上主库，但发现alert.log中不断iblogfile pos不一致，很好奇myisam为什么会用到redo log，结果扫了下整个数据目录在众多myisam表中参杂了10张innodb表，汗，第二次恢复失败

快照并没有记录缓存中的信息，停掉slave然后做快照吧，然后之前的方式搭建起来，启动正常无报错，然后在剩下几个slave都搭起来指向新master，而新master指向了需求方那边的master，新master很快就同步了，但是几个slave延迟却越来越大，观察到很大的读iops，尝试调整了几个参数，比如调高key_buffer_size，但是也没什么效果，最后突然想起之前在innodb上遇到的无主键删除case，查看了最大的myisam表竟然没有主键，谜底终于揭晓了，但是几个slave也废掉了，第三次恢复失败

新master调整binlog_format=STATEMENT 和tx_isolation=REPEATABLE-READ（在statement模式下，READ-COMMITTED隔离级别是不安全的），tx_isolation可以动态修改，但在statement模式下，建议使用--transaction-isolation=REPEATABLE-READ作为mysqld启动项，然后关实例，物理拷贝到slave上，重新搭建，目前所有实例都已经同步了，第四次恢复成功

随后又遇到表名大小写的场景，通过lower_case_table_names=0解决，接着就是不断swap，最终查到原因是与部署的cgroup策略冲突的问题

一般情况下复制集群中会有一个实例提供binlog抓取，binlog_format需要调整从statement改为row，选择一个备库，确认没有应用链接，调整了动态参数和my.cnf文件，flush logs后但解析binlog后发现还是statement模式，百思不得其解，最终通过stop slave;start slave;解决了，global级别参数值调整不会改变已存在session级别参数值，解决方式很简单，但排查绕了很大弯子，解决问题的思路还不够清晰，快速诊断需要加强

myisam一直都没用过，如果不是这个case不会对其有所了解，myisam对我来说还有太多未解之谜，不过留给后人吧，俺还是喜欢innodb，记录下整个迁移过程，说不定哪天还会有类似的需求，走了一些弯路，明确需求，充分沟通，取长补短，这是我最大的收获