快速搭建MySQL主从系统

一、操作步骤

1.1 配置主节点

1.1.1 开启mysql binlog,设置唯一服务ID

在配置文件/etc/my.cnf 增加以下内容

#集群中唯一即可
server-id=100 
#开启binlog并设置文件名为mysql-bin
log-bin=mysql-bin 

1.1.2 重启mysql服务

service mysqld restart

1.1.3 创建用户并授权同步权限

create user ‘slave’@‘%’ IDENTIFIED BY 'your password';
grant  replication slave, replication client on *.* TO 'slave'@'%';

1.1.4 查看当前binlog文件名和日志已写入点位position

show master status;

记录下用于配置从节点

1.2 配置从节点

1.1.1 设置唯一服务ID

在配置文件/etc/my.cnf 增加以下内容

#集群中唯一即可,与主节点区分
server-id=101

1.1.2 重启mysql服务

service mysqld restart

1.1.3 进入从库mysql，配置需要复制的主节点信息

change master to
 master_host = "xxx.xxx.xxx",//主节点ip地址
 master_port = 3306, //master数据库端口
 master_user = "slave",//master上创建用于数据备份的用户
 master_password = "123456",//master上创建的用户密码
 master_log_file = "mysql-bin.000001", //master上binlog文件名
 master_log_pos = 120;//读取binlog文件偏移量

在执行之前最好在slave上，使用master上创建的账户尝试连接master mysql，如果连接正常，则可继续执行，要注意binlog文件名和pos点位必须配置正确。

1.1.4 开启主从复制

start slave;

1.1.5 查看从节点复制状态

show slave status\G

Slave_IO_Running 和Slave_SQL_Running 都是Yes说明主从复制已经正常开启。

1.1.6 验证复制

1. 在master 上创建库，表，新增更新数据

2. 在slave上查询master上操作后的数据

二、部署中常见问题

2.1 Slave_IO_Running 一直显示为 connecting状态，

若Slave_IO_Running一直是Connecting，可能是下面4种原因：

a、主从节点网络不通，检查ip端口

b、密码不对，检查配置的主节点用户名和密码

c、pos不对，检查Master的Position

总结来说，肯定是主从配置的信息不对

2.2 Fatal error: The slave I/O thread stops because master and slave have equal MySQL server UUIDs; these UUIDs must be different for replication to work.

找到data文件夹下的auto.cnf文件，修改里面的uuid值，保证各个db的uuid不一样，重启db即可

2.3 Fatal error: The slave I/O thread stops because master and slave have equal MySQL server ids; 

找到my.cnf配置文件中的server_id，修改从库的server_id保证和复制结构中的其他db不一样，重启db即可

三、扩展和原理

3.1 mysql 主从复制基本原理

mysql主从同步涉及三条线程：主节点：binary log dump thread，从节点：I/O thread ，SQL thread。步骤简单描述如下：

a. 从节点上执行start slave命令之后，从节点会创建一个I/O线程用来连接主节点，（请求主库中更新的bin-log）。 b. 当一个从节点连接主节点，主节点会创建一个 binary log dump thread ，（用于发送bin log 日志到从节点）。 c. I/O线程接收到主节点binlog dump 线程发来的更新之后，保存在本地relay-log（中继日志）中。

d. SQL线程负责读取relay log中的内容，解析成具体的操作并执行

主从复制原理图-转载

3.2. master 与slave之间如何实时数据同步的, pull还是push

a. slave IO thread 使用配置的username，password，bin log filename和position 信息请求连接master，连接成功后，master 创建 binary log dump thread ，把指定filename的position后更新的log data 发送给slave。

b. master 上的log dump thread 负责维护与slave IO thread 之间的长连接，并监听当前写入的bin log，当有新的事件的bin log写入成功后，会触发binary log dump thread 发送最新的bin log给 slave IO thread。(主动PUSH)

binary log dump thread 读取binary log时会对binary log加锁，读取完成后立即释放锁，即使此时读取的数据还并没有发送slave。

3.3. slave宕机重启后，是否还需要通过start slave建立主从连接？

不需要。slave在本地磁盘上master.info文件中维护了master信息，包括同步的binary log filename及最后同步的position。

执行命令show slave status\G; 结果中Master_Info_File字段的值便是master.info文件的位置。

slave在宕机重启后读取master.info文件，根据维护的master信息自动创建I/O thread 与master重新建立连接，并且创建SQL thread。

3.4. SQL thread 的执行机制，是实时监听relay-log还是定时拉取？ 单线程执行？

a. 根据SQL thread 的状态描述 “Slave has read all relay log; waiting for more updates”，是一种监听机制，每当relay-log有新增时，便读取并执行。

b. 根据查阅相关资料，mysql5.5版本及之前是仅支持单线程的。但是为了提高同步效率，从mysql 5.6 版本开始支持多线程模式，并且从5.6 - 5.7的各个版本中对多线程复制策略都有新的迭代。大概的思路图如下,

coordinator 就是原来的 sql_thread, 不过现在它不再直接更新数据了，只负责读取中转日志和分发事务。真正更新日志的，变成了 worker 线程，由多个worker线程并行执行复制。

多线程同步