MySQL的主备同步

一、原理
A：主库
B：备库

1、主库接受到客户端发送的一条update语句，执行内部事务逻辑，同时写入binlog。
2、备库通过 change master 命令，设置主库的IP、端口、用户名和密码，以及要从哪个位置开始请求 binlog。这个位置包含文件名和偏移量。
3、在备库上执行start slave命令，启动两个线程 io_thread 和 sql_thread，其中 io_thread 负责与主机进行连接。
4、主库校验完用户名和密码，按照接收到的位置去读取binlog，发给备库。
5、备库接收到binlog后，写到本地文件(relay log，中转文件)。
6、备库读取中转文件，解析出命令，然后执行。
总结：主备同步的工作原理其实就是一个完全备份加上二进制日志备份的还原。不同的是这个二进制日志的还原操作基本上是实时的。

备库通过两个线程来实现同步：
1、一个是 I/O 线程，负责读取主库的二进制日志，并将其保存为中继日志。
2、一个是 SQL 线程，负责执行中继日志。

二、切换流程
1、M-S结构
两个节点，一个当主库、一个当备库，不允许两个节点互换角色。
正常情况下，客户端的读写都直接访问节点A，而节点B是A的备库，只是将A的更新都同步过来，到本地执行。这样可以保持节点B和A的数据是相同的。
当需要切换的时候，此时候客户端读写访问的都是节点B，而节点A是B的备库。
2、双M结构
双M结构，两个节点，一个当主库，一个当备库，允许两个节点互换角色。在A和B之间其实多了一条线，即节点A和B之间总是互为主备关系。这样在切换的时候就不用再修改主备关系。

三、循环复制的问题
1、问题：在A执行update语句时，生成binlog并发送给B，而B同步完成后，也会生成binlog（log_slave_updates设置为on，表示备库也会生成binlog）。而当A也是B的备库时，则B也会把binlog发送给A，造成循环复制。
2、解决方案：为每个节点设置server-id。当备库收到binlog后，比效server-id，如果相同，则丢弃。