前言:
在MySQL中,主从架构应该是最根底、最罕用的一种架构了。后续的读写拆散、多活高可用架构等大多都依赖于主从复制。主从复制也是咱们学习MySQL过程中必不可少的一部分,对于主从复制的文章有很多,笔者也来凑凑热闹,写写这方面的内容吧,同时分享下本人的教训和办法。
1.主从复制简介及原理
主从复制(也称 AB 复制)是指一台服务器充当主数据库服务器,另一台或多台服务器充当从数据库服务器,主服务器中的数据主动复制到从服务器之中。对于多级复制,数据库服务器既可充当主机,也可充当从机。MySQL默认采纳异步复制形式。
主从复制的过程及原理能够总结如下:
- master服务器将数据的扭转记录二进制binlog日志,当master上的数据产生扭转时,则将其扭转写入二进制日志中。
- slave服务器会在肯定工夫距离内对master二进制日志进行探测其是否产生扭转,如果产生扭转,则开始一个I/OThread申请master二进制事件。
- 同时主节点为每个I/O线程启动一个dump线程,用于向其发送二进制事件,并保留至从节点本地的中继日志中,从节点将启动SQL线程从中继日志中读取二进制日志,在本地重放,使得其数据和主节点的保持一致。
2.基于二进制文件地位配置主从复制
基于二进制文件地位的主从复制又能够称为传统复制,即从服务器依赖于主服务器的binlog文件地位,当主库产生数据变更时,binlog pos位点会增长,从库会感应到变动来实现同步。
配置主从复制,咱们首先要筹备至多两台MySQL实例,一台充当主服务器、一台充当从服务器。因为主从复制依赖于binlog,所以主库必须开启binlog,且主从要配置不同的server_id,上面具体展现下配置过程:
2.1 确认主从库配置参数
MySQL主从服务器倡议有如下配置,能够先确认下,如果未配置,则须要批改配置文件而后重启。
# 主库参数配置 要有以下参数vim /etc/my.cnf [mysqld] log-bin = binlog //启用二进制日志server-id = 137 //服务器惟一ID,默认值是1,个别设置为IP地址的最初一段数字binlog_format = row //bilog设置为row模式 避免复制出错# 从库倡议配置以下参数vim /etc/my.cnf [mysqld] relay-log = relay-binserver-id = 138
2.2 确定主库二进制地位,创立同步账号
若主从库都是刚刚初始化实现,且主库无操作时,从库可不必同步主库的数据,间接确定主库的binlog地位即可。
# 查看主库binlog文件地位show master status;# 主库创立同步账号create user 'repl'@'%' identified by '123456';grant replication slave on *.* to 'repl'@'%';
若主库曾经运行了一段时间,有业务数据在,而从库刚刚初始化实现,此时则须要备份主库的数据,而后导入从库,使得主从数据统一。
# 主库创立同步账号create user 'repl'@'%' identified by '123456';grant replication slave on *.* to 'repl'@'%';# 全备主库数据mysqldump -uroot -pxxxx -A -R -E --single-transaction --master-data=2 > all_db.sql# 从库端复原mysql -uroot -pxxxx < all_db.sql# 从备份文件中能够找到主库的binlog地位
2.3 进入从库,开启主从复制
找到主库二进制文件地位且实现主从数据统一后,咱们就能够正式开启主从复制了。
# 进入从库MySQL命令行 执行change master语句连贯主库# 二进制文件名及pos地位由下面步骤取得CHANGE MASTER TO MASTER_HOST='MySQL主服务器IP地址', MASTER_PORT=3306, MASTER_USER='repl', MASTER_PASSWORD='123456', MASTER_LOG_FILE='binlog.000002', MASTER_LOG_POS=154; # 开启主从复制 并保持状态start slave;show slave status \G //查看slave状态 确保Slave_IO_Running: Yes Slave_SQL_Running: Yes
3.基于GTID的主从复制
GTID是MySQL 5.6的新个性,其全称是Global Transaction Identifier,可简化MySQL的主从切换以及Failover。GTID用于在binlog中惟一标识一个事务。当事务提交时,MySQL Server在写binlog的时候,会先写一个非凡的Binlog Event,类型为GTID_Event,指定下一个事务的GTID,而后再写事务的Binlog。
在基于GTID的复制中,首先从服务器会通知主服务器曾经在从服务器执行完了哪些事务的GTID值,而后主库会有把所有没有在从库上执行的事务,发送到从库上进行执行,并且应用GTID的复制能够保障同一个事务只在指定的从库上执行一次,这样能够防止因为偏移量的问题造成数据不统一。也就是说,无论是级联状况,还是一主多从的状况,都能够通过GTID主动找地位,而无需像之前那样通过File_name和File_position找主库binlog地位了。
基于GTID的主从复制与下面基于二进制文件地位的主从复制搭建步骤相似,同样简略展现下搭建过程:
3.1 确认主从库配置,开启GTID
# 主库参数配置 要有以下参数vim /etc/my.cnf [mysqld] server-id = 137log-bin = binlog binlog_format = row gtid-mode = ON //开启gtid模式enforce-gtid-consistency = ON //强制gtid一致性,用于保障启动gitd后事务的平安 # 从库倡议配置以下参数vim /etc/my.cnf [mysqld] server-id = 138log-bin = binlog binlog_format = row gtid-mode = ON enforce-gtid-consistency = ON relay-log = relay-bin
3.2 创立同步账号,放弃主从库数据统一
若主库刚初始化实现或者主库端保留有全副二进制文件,则从库无需手动同步数据。否则须要手动同步数据使得主从统一。
# 主库创立同步账号create user 'repl'@'%' identified by '123456';grant replication slave on *.* to 'repl'@'%';# 若主库刚初始化或保留有残缺二进制文件 则无需执行上面步骤# 全备主库数据mysqldump -uroot -pxxxx -A -R -E --single-transaction > all_db.sql# 从库端复原mysql -uroot -pxxxx < all_db.sql
3.3 进入从库,开启主从复制
# 进入从库MySQL命令行 执行change master语句连贯主库CHANGE MASTER TO MASTER_HOST='MySQL主服务器IP地址', MASTER_PORT=3306, MASTER_USER='repl', MASTER_PASSWORD='123456', MASTER_AUTO_POSITION = 1; # 开启主从复制 并保持状态start slave;show slave status \G
4.一些教训及倡议
在日常学习及工作过程中,主从复制方面也积攒了一些教训,上面简略分享几点,心愿各位少踩坑。
- 主从两端数据库版本尽量保持一致。
- 主从库参数倡议雷同,比方字符集、sql_mode这类参数要设置一样。
- 从库服务器性能不能过于落后主库,免得因服务器性能产生主从提早。
- 所有表强制领有主键,因为无主键表同步到从库极易产生主从提早。
- 倡议从库设为read only,以防人为误操作从库数据。
- 监控主从提早及状态,及时解决同步中断或提早问题。
总结:
本文介绍了主从复制的原理及搭建过程,其实对于主从复制的内容还有很多,须要一直的学习。这里举荐大家应用GTID模式来搭建主从复制,对于前面分享的几点教训,也是本人日常积攒的,心愿对你有所帮忙。写作不易,感觉还不错的话,请棘手转发分享下哦。