MySQL主从架构部署及同步原理

一般MySQL的主从架构的目的都是用来做读写分离，分担主库的负载压力，主库用来写，从库用来读。

MySQL主从架构部署

1.在两台不同机器上分别部署好MySQL数据库。部署步骤见：Linux离线安装MySQL 5.7(最详细)

master	主库
server.id = 6867
expire_logs_days = 7
binlog_format = ROW
log-bin = /usr/local/mysql/arch/mysql-bin
	
slave	从库
server.id = 6868

注意：两台机器的MySQL配置文件中 server.id 必须不一样。

2.在主库上创建复制用户

mysql> grant replication slave on *.* to repluser@'%' identified by 'ruozedata';
mysql> flush privileges;

3.查看pos点
主库执行：

mysql> show master status;
+-----------------+---------+------
|File             |Position | ……
+-----------------+---------+------
|mysql-bin.000002 |     989 | ……
+-----------------+---------+------

从库执行：

mysql> change master to 
master_host='192.168.0.76',
master_port=3306,
master_user='repluser',
master_password='ruozedata',
master_log_file='mysql-bin.000002',
master_log_pos=989;

mysql> start slave;
mysql> show slave status\G;

若是运行时报错没有找到/usr/local/mysql/relay_log文件夹就手动创建。

运行 show slave status\G; 主要查看2个指标：

Slave_IO_Running: YES
Slave_SQL_Running: YES

若都是YES状态，说明主从同步状态正常。这时主从部署就完成了，可在主库上写，从库上读。

同步原理

主库写数据，会以二进制形式保存到磁盘的binarylog文件中。
从库读取主库的binarylog文件到本地（IO thread），保存到 relay_log 文件中，并重演SQL到从库中（SQL thread）。

故障案例

生产上某次执行 show slave status\G 后出现如下信息：

……
Slave_IO_Running: YES
Slave_SQL_Running: No
……

Slave_SQL_Running的状态不对了，说明从库同步主库数据没问题，问题出在SQL重演上。

解决办法：
从库：

mysql> stop slave;

主库：

bin/mysqlbinlog --no-defaults --base64-output=decode-rows -v -v /usr/local/mysql/arch/mysql-bin.000002 > 2.sql

执行后生成 2.sql 文件，查看文件发现：主库执行了一个删除某条数据的操作，但从库没有这条数据可以删除，所以抛错。
从库：

mysql> set global sql_slave_skip_counter=1;
mysql> start slave;
mysql> show slave status\G;  看两个YES

总结：说明MySQL的主从同步并不是实时的，也是定时离线同步。

思考

如何做：主-从-从架构（并行和串行两种形式）