MySQL主从

MySQL主从

1、什么是mysql主从同步？

当master(主)库的数据发生变化的时候，变化会实时的同步到slave(从)库。

2、主从同步有什么好处？

1. 提高数据库的性能，在主服务器上执行写入和更新，在从服务器上向外提供读功能，可以动态地调整从服务器的数量，从而调整整个数据库的性能。
2. 容错，高可用。Failover(失败切换)/High Availability。
3. 数据备份。
4. 在主服务器上生成实时数据，而在从服务器上分析这些数据，从而提高主服务器的性能。

3、主从同步的机制

不管是delete、update、insert，还是创建函数、存储过程，所有的操作都在master上。当master有操作的时候,slave会快速的接收到这些操作，从而做同步。

在master机器上，主从同步事件会被写到特殊的log文件中(binary-log)；在slave机器上，slave读取主从同步事件，并根据读取的事件变化，在slave库上做相应的更改。

在master机器上的操作

在master机器上，主从同步事件会被写到特殊的log文件中(binary-log)；

当slave连接到master的时候，master机器会为slave开启binlog dump线程。当master 的 binlog发生变化的时候，binlog dump线程会通知slave，并将相应的binlog内容发送给slave。

在slave机器上的操作

当主从同步开启的时候，slave上会创建2个线程。

1. I/O线程。该线程连接到master机器，master机器上的binlog dump线程会将binlog的内容发送给该I/O线程。该I/O线程接收到binlog内容后，再将内容写入到本地的relay log。
2. SQL线程。该线程读取I/O线程写入的relay log。并且根据relay log的内容对slave数据库做相应的操作。

4、主从同步的日志

主从同步事件有3种形式：statement、row、mixed。

• statement：会将对数据库操作的sql语句写入到binlog中。
• row：会将每一条数据的变化写入到binlog中。
• mixed：statement与row的混合。Mysql决定什么时候写statement格式的，什么时候写row格式的binlog。

对应的方法为：

• SBR：当使用二进制日志时，主服务器会把SQL语句写入到日志中，然后从服务器会执行该日志，在mysql5.1.4之前的版本都只能使用这种格式。
• RBR：主服务器把表的行变化作为事件写入到二进制日志中，主服务器把代表了行变化的事件复制到从服务中。
• MBR：既使用SBR也使用RBR，默认使用SBR。

三种方法的优劣：

1.SBR

长处：

1. 日志文件更小
2. 记录了所有的语句，可以用来日后审计

弊端：

1. 使用如下函数的语句不能被正确地复制：load_file(); uuid(), uuid_short(); user(); found_rows(); sysdate(); get_lock(); is_free_lock(); is_used_lock(); master_pos_wait(); rand(); release_lock(); sleep(); version();
2. 在日志中出现如下警告信息的不能正确地复制：[Warning] Statement is not safe to log in statement format.
3. 或者在客户端中出现show warnings
4. Insert … select语句会执行大量的行级锁表
5. Update语句会执行大量的行级锁表来扫描整个表

2.RBR

长处：

1. 所有的数据变化都是被复制，这是最安全的复制方式
2. 更少的行级锁表

弊端：

1. 日志会很大
2. 不能通过查看日志来审计执行过的sql语句，

5、主从同步的三种选择

（1）异步复制

异步复制是MySQL默认的复制方式，主库写入binlog日志后即可成功返回客户端，无须等待binlog日志传递给从库的过程，但是一旦主库宕机，就有可能出现丢失数据的情况。
　　具体流程为，主库事务完成后，写入binlog日志完成直接返回客户端，由主库的异步线程：binlog dump线程，异步的将binlog传递给从库。

（2）半同步复制

MySQL默认的复制方式是异步复制，但是当主库宕机，在高可用架构坐准备切换，就会造成新的主库丢失数据的现象。

MySQL5.5版本之后引入了半同步复制，但是主从服务器必须同时安装半同步复制插件。在该功能下，确保从库接收完成主库传递过来的binlog内容已经写入到自己的relay log后才会通知主库上面的等待线程。如果等待超时(超时参数：rpl_semi_sync_master_timeout)，则关闭半同步复制，并自动转换为异步复制模式，直到至少有一台从库通知主库已经接收到binlog信息为止。

注意，master不保证slave完成写入，它只保证binlog写到slave的relay log中，就返回。后面slave自己开始写数据，完不完成是它自己的事。

流程如下：

1. master开启事务。
2. 发送binlog给slave。
3. slave接受binlog并将其写入ready log。
4. slave返回确认号ACK给master。
5. master事务结束。
6. slave开始读ready log中的日志，并同步数据。

（3）全同步模式

全同步模式是指主节点和从节点全部执行了commit并确认才会向客户端返回成功。

（4）GTID复制

GTID又叫全局事务ID，是一个以提交事务的编号，并且是一个全局唯一的编号。GTID是由server_uuid和事务id组成的，即GTID=server_uuid:transaction_id。

server_uuid是数据库启动自动生成的，保存在auto.cnf文件下，transaction_id是事务提交时由系统顺序分配的一个不会重复的序列行。

GTID存在的价值：

1. GTID使用master_auto_position=1代替了基于binlog和position号的主从复制方式，更便于主从复制的搭建。
2. GTID可以知道事务在最开始是哪个实例上提交的。
3. GTID方便实现主从之间的fail over，无须找position和binlog。

GTID限制条件：

1. 不能使用create table table_name select * from table_name。
2. 不支持CREATE TEMPORARY TABLE or DROP TEMPORARY TABLE语句操作。
3. 不支持sql_slave_skip_counter。

注意：mysql是异步复制的，而MySQL Cluster是同步复制的。

（5）复制出错处理

常见：1062（主键冲突），1032（记录不存在）
解决：

1. 手动处理
2. 跳过复制错误：set global sql_slave_skip_counter=1

https://www.cnblogs.com/Aiapple/p/5792939.html