MySQL主从同步
单台服务器在企业业务不断发展中必然会遇到访问压力与单点故障,主从复制的架构在一定程度上解决了这个问题。一方面可以实现流量分流,可以让外部请求直接访问主库,内部人员访问从库;另一方面,从库可以当做备份服务器实现主库故障时的手动切换,以满足正常运行的基本要求。
主从同步基本原理
主库打开binlog日志记录功能,主从同步就是从库去主库上获取这个binlog日志,并且将binlog日志中记录执行的SQL语句在从库上执行一次
从库上执行
start slave
命令即可开始主从同步,主从的数据复制就开始了主从同步开始进行后,从库上的I/O线程就会发送验证请求到主库请求建立连接,并指定位置(这个位置是在从库上执行
chage master
时指定的)后的binlog日志主库在收到从库的验证请求后会返回从库请求的内容,这些内容包括binlog日志的内容,主库中新纪录binlog日志的名称以及新的binlog日志中下一个指定位置点等信息
从库收到主库发送来的binlog日志后会将其存在relay log中,并将新的binlog文件名以及位置点信息存储在master.info文件中
从库的SQL线程会实时查看本地relay log线程新增的内容,然后把relay log文件中的内容解析为SQL语句并顺序的在从库一一执行,最后将当前服务器中的中继日志的文件名及位置点信息存储在relay-log.info中以便下次同步需要
主从同步部署
1、服务器环境配置:
IP | 角色 | 操作系统 |
---|---|---|
106.14.14.122 | 主数据库 | CentOS7.8 |
101.132.38.235 | 从数据库 | CentOS7.8 |
本篇博客仅仅是部署测试,现实环境应最大可能使用内网ip。
2、数据库安装:
3、主数据库开始binlog日志
在主数据库的配置文件中添加log_bin,开启记录bin_log日志,文件名为mysql-bin
|
|
重启数据库后会发现在/opt/mysql/data
目录中会生成两个文件mysql-bin.000001
和mysql-bin.index
,mysql-bin.000001
是记录binlog日志的文件,而index是存放mysql-bin文件名的文件
|
|
实际同步中,为了安全考虑,主数据库的用户授权信息是不会同步给从库的,这就必须显式的在配置文件中告诉mysql在不要同步mysql库 。如果binlog-format是ROW模式,那么忽略同步mysql库的语法是replicate-wild-ignore-table=mysql.%
;如果是STATEMENT模式,语法为replicate-ignore-db=mysql
。
此项配置需写在从库的配置文件中
|
|
binlog 三种格式
ROW
ROW格式会记录每行记录修改的记录,这样可能会产生大量的日志内容,比如一条update语句修改了100条记录,那么这100条记录的修改都会被记录在binlog日志中,这样造成binlog日志量会很大,这种日志格式会占用大量的系统资源,mysql5.7和myslq8.0安装后默认就是这种格式。
STATEMENT
记录每一条修改数据的SQL语句(批量修改时,记录的不是单条SQL语句,而是批量修改的SQL语句事件)所以大大减少了binlog日志量,节约磁盘IO,提高性能,看上面的图解可以很好的理解row和statement 两种模式的区别。但是STATEMENT对一些特殊功能的复制效果不是很好,比如:函数、存储过程的复制。由于row是基于每一行的变化来记录的,所以不会出现类似问题
MIXED
实际上就是前两种模式的结合。在Mixed模式下,MySQL会根据执行的每一条具体的sql语句来区分对待记录的日志形式,也就是在Statement和Row之间选择一种。
4、主库配置同步用户并对从库授权
|
|
查看主库状态
|
|
5、配置从库
|
|
查看从库同步状态
|
|
发现Slave_IO_Running: No
报错,查看日志发现
|
|
关键信息是说主库与从库的server id一样,因为是脚本批量安装,造成了所有服务器server-id=1,手动将从数据库的server-id改为2并重启,再次检查从库状态,发现两个均为YES。至此,主从同步部署完成。
主从同步测试
主库创建新库新表并写入测试数据
|
|
登录从库查看
|
|
数据同步完成