MySQL主从复制
配置MySQL主从复制,先来讲讲一些理论。
MySQL复制功能提供分担读负载。
基于二进制日志的复制是异步的,那么复制有什么好处?
1.实现在不同服务器上的数据分布,利用二进制日志增量进行,不需要太多带宽,但是使用基于行的复制在进行大批量的更改时,会对带宽带来一定的压力。特别是跨IDC环境下进行复制,应该分批进行。
2.实现数据读取的负载均衡。可以通过DNS轮询的方式把程序的读连接分配到不同的备份数据库中。还有可以通过LVS+Keepalived等等。
3.增强了数据安全性,利用备库的备份来减少主库负载,还可以避免单点故障。值得注意的是,复制并不能替代备份。
4.实现数据库在线升级。
说到日志,MySQL的服务层日志有二进制日志,慢查询日志,通用日志。而存储引擎的日志有innodb的重做日志(Redo log),回滚日志(Undo log)。
Redo Log:可以实现事务的持久性。用于记录某数据块被修改后的值,可以用来恢复未写入data file的已成功事务更新的数据。通常会初始化2个或更多的 ib_logfile 存储 redo log,由参数 innodb_log_files_in_group 确定个数,命名从 ib_logfile0 开始,依次写满 ib_logfile 并顺序重用。如果最后1个 ib_logfile 被写满,而第一个ib_logfile 中所有记录的事务对数据的变更已经被持久化到磁盘中,将清空并重用之。
image.png image.png
Undo Log:未提交的事务,独立于表空间,需要随机访问,可以存储在高性能IO设备中。存放于ibdata中。
image.png
Undo日志记录某数据被修改前的值,可以用来在事务失败时进行rollback;Redo日志记录某数据块被修改后的值,可以用来恢复未写入data file的已成功事务更新的数据。
那么二进制日志是什么?
二进制日志记录了所有对MySQL数据库的修改事件,包括了增删查改事件和对表结构进行修改的事件。
二进制日志格式,可以设置基于段的格式,比如binlog_format=statement
。
基于段的格式,优点是:日志记录相对较小,节约磁盘网络IO。缺点是:必须要记录上下文信息,保证语句在slave上执行的结果和master上相同。
而基于段的格式binlog_format=row
适用于只对一条记录修改或者插入,此时所产生的日志量小于段产生的日志量。
环境配置如下:
1.master(192.168.10.21) MySQL 5.7.17
2.slave(192.168.10.6) MySQL 5.7.17
给master创建sync用户并分配所需权限。
grant all privileges on *.* to sync@'%' identified by 'sync' \g
image.png
给slave创建sync用户并分配所需权限。
grant all privileges on *.* to sync@'%' identified by 'sync' \g
image.png
修改master的配置文件
image.png
修改slave的配置文件
image.png
在master查看binlog
SHOW BINARY LOGS
FLUSH BINARY LOGS #刷新binlog
SHOW BINARY LOGS
image.png
在slave查看binlog
SHOW BINARY LOGS
image.png
我们在配置slave的时候,不要对master进行操作。每次在master进行CRUD和对表结构进行修改时,binlog会发生变化。
在slave中,配置master相关的信息。
mysql> change master to
-> master_host="192.168.10.21",
-> master_user="sync",
-> master_password="sync",
-> master_log_file="mysql-bin.000002",
-> master_log_pos=154\g
Query OK, 0 rows affected, 2 warnings (0.02 sec)
启动slave。
image.png
查看slave运行状态,Slave_IO_Running和Slave_SQL_Running都为yes的话,说明slave运行没问题。
SHOW SLAVE STATUS
image.png
image.png
在master创建测试库rap_test,我们发现binlog也发生了变化。
image.png
image.png
我们查看master的状态
SHOW MASTER STATUS
image.png
我们再来查看slave的状态,发现slave已经复制成功了。
-
The position, ON THE MASTER, from which the I/O thread is reading: Master_Log_File/Read_Master_Log_Pos. —–相对于主库,从库读取主库的二进制日志的位置,是IO线程
-
The position, IN THE RELAY LOGS, at which the SQL thread is executing: Relay_Log_File/Relay_Log_Pos —-相对于从库,是从库的sql线程执行到的位置
-
The position, ON THE MASTER, at which the SQL thread is executing: Relay_Master_Log_File/Exec_Master_Log_Pos —-相对于主库,是从库的sql线程执行到的位置
更多返回参数说明可以参考show slave status 参数详解
mysql> show slave status \G
*************************** 1. row ***************************
Slave_IO_State: Waiting for master to send event
Master_Host: 192.168.10.21
Master_User: sync
Master_Port: 3306
Connect_Retry: 60
Master_Log_File: mysql-bin.000002
Read_Master_Log_Pos: 1119
Relay_Log_File: localhost-relay-bin.000002
Relay_Log_Pos: 541
Relay_Master_Log_File: mysql-bin.000002
Slave_IO_Running: Yes
Slave_SQL_Running: Yes
Replicate_Do_DB:
Replicate_Ignore_DB:
Replicate_Do_Table:
Replicate_Ignore_Table:
Replicate_Wild_Do_Table:
Replicate_Wild_Ignore_Table:
Last_Errno: 0
Last_Error:
Skip_Counter: 0
Exec_Master_Log_Pos: 1119
Relay_Log_Space: 752
Until_Condition: None
Until_Log_File:
Until_Log_Pos: 0
Master_SSL_Allowed: No
Master_SSL_CA_File:
Master_SSL_CA_Path:
Master_SSL_Cert:
Master_SSL_Cipher:
Master_SSL_Key:
Seconds_Behind_Master: 0
Master_SSL_Verify_Server_Cert: No
Last_IO_Errno: 0
Last_IO_Error:
Last_SQL_Errno: 0
Last_SQL_Error:
Replicate_Ignore_Server_Ids:
Master_Server_Id: 21
Master_UUID: 67ccaaf1-e4b4-11e7-a07f-c8d3ffc0c026
Master_Info_File: /usr/local/mysql/data/master.info
SQL_Delay: 0
SQL_Remaining_Delay: NULL
Slave_SQL_Running_State: Slave has read all relay log; waiting for more updates
Master_Retry_Count: 86400
Master_Bind:
Last_IO_Error_Timestamp:
Last_SQL_Error_Timestamp:
Master_SSL_Crl:
Master_SSL_Crlpath:
Retrieved_Gtid_Set:
Executed_Gtid_Set:
Auto_Position: 0
Replicate_Rewrite_DB:
Channel_Name:
Master_TLS_Version:
1 row in set (0.00 sec)
我们在slave中也看到了rap_test库,说明从库复制成功。
image.png
打开slave中的localhost-relay-bin.000002文件,可以看到sql线程执行了create database rap_test语句。
image.png
另外我们可以通过show slave status命令返回的Seconds_Behind_Master参数查看主从延迟状态。
image.png