MySQLReplication GTID方式
由于需要迁移线上数据到一个新的Mysql服务器并且不影响在线业务，需要维持迁移过程中应用程序的大部分可用。因此不可能对线上的Mysql服务器进行停机处理，所采用的的方式也就是通过Replication的方式，保持主从复制，在逐步修改应用程序的链接数据，最后停掉主从来达到这个目的。由于应用上的微服务架构，不存在一个应用程序访问多个数据这个问题，所以当应用程序切换的时候数据是安全的。
首先关于Mysql主从有从mysql 5.6开始就有了两种方式，一种是对传统的binlog position方式，另外一种是就是本文的介绍的GTID方式的主从复制。
所谓的GTID就是全局的事务ID，Mysql采用一个全局的事务ID并把事务ID写在bin-log中来进行的主从复制中事务位置的区分的，区别于之前主从复制需要制定bln-log文件的名称和开始的位置这个方式无疑有了更大的灵活性。需要注意的是GTID方式并不是完全不依赖的binlog的一种全新方式，只是在原有基础上的改进，采用这种方式能更好的实现热数据的迁移和故障节点的恢复等。
下面来看下如何实现，首先GTID也是需要开启binlog的，也需要在两台服务器上都开启GTID这个功能，看如下配置文件：
server-id=1 # 制服务器唯一ID
binlog-ignore-db=mysql # 忽略binlog的数据库
log-bin=macco-mysql-bin # binlog的前缀
binlog_cache_size=1M
binlog_format=row # binlog的格式，推荐为row也可以mix
gtid_mode=ON #开启GTID
enforce-gtid-consistency=ON # GTID持久化
log-slave-updates # 不加的话，如果之前没有开启过gtid这个功能会出错。
配置完成后，先将mysql master节点设置为只读
set global.readonly = ON
此时App能正常访问但是不能读取数据，快速重启mysql后将只读属性取消
set global.readonly = OFF
在master节点上建立Replication的用户
GRANT REPLICATION SLAVE ON *.* TO 'repl'@'XXX.XXX.XXX' IDENTIFIED BY 'pass';
配置Slave节点，区别是server-id可以不同。
下面是将主节点数据dump出来，用于到从节点恢复
mysqldump -uroot -pKitche931743 -h127.0.0.1 -q -R --triggers --opt --single-transaction --flush-logs --master-data=2 --all-databases > all_database_latest.sql
复制该文件到从数据库上执行
下面是开始配置从服务器。
CHANGE MASTER TO
> MASTER_HOST = host,
> MASTER_PORT = port,
> MASTER_USER = user,
> MASTER_PASSWORD = password,
> MASTER_AUTO_POSITION = 1;
执行完成后
show warnnings
看下警告，如果没有什么异常的话，启动复制
start slave #启动
show slave status #查看状态
如此就可以完成主从的配置
本文为Lokie.Wang原创文章,转载无需和我联系,但请注明来自lokie博客http://lokie.wang
- 最新评论
- 总共0条评论
