mysql高可用方案，MySql主从复制原理及配置，binLog和GTID

那什么时候写binlog呢？事务提交有两个阶段：prepare与commit，是哪个阶段写binlog呢？binlog其实是在prepare后commit前写入的，同时写事务过程中，会产生redolog与undolog。binlog是MySQL Server层的日志，而redolog是MySQL引擎InnoDB层的日志。

redolog和undolog：innodb事务日志包括redo log和undo log。redo log是重做日志，提供前滚操作，undo log是回滚日志，提供回滚操作。详见：https://www.cnblogs.com/f-ck-need-u/p/9010872.html

binlog 和 redolog，这两者有什么区别呢？

1. binlog是MySQL Server层的日志，而redolog是MySQL引擎InnoDB层的日志

2. 另外一个不同是两者写入时机不同，redolog是prepare阶段每执行sql语句就写redo了，而binlog是在prepare完commit前写的。

那MySQL在主从架构下怎么保证数据一致性呢？众所众知，MySQL为了保证性能，数据是先写内存后落盘的。当你数据库运行的时候，发生了宕机，机器再次恢复的时候可能是部分数据落盘了，部分未落盘。这时，mysql是找到binlog最新同步的位点或GTID，来确定redolog或者undolog中哪些实例需要回滚，哪些事务需要重做。

GTID

要知道主服务器在Binlog中存放了大量信息，而从服务器显然只需求缺少的那部分Binlog信息，那该怎么办？

主、从商量之后，决定给每条Binlog信息都添加一个双方都认识的自增编号，让主服务器中所有的Binlog信息有序排列，这样在从服务器下一次请求时，只需告诉主服务器我现在使用的Binlog编号是多少，主服务器就明白哪些信息是从服务器需要的了。

这个编号我们将它命名为GTID（Global Transaction ID），作为一个全局事务的ID，必须保证其全局唯一性，每台MySQL服务器都会有属于自己的服务器ID，称之为server_uuid，而每一条Binlog信息都以事务为单位，也拥有相应的事务ID，称之为transaction_id，我们将两者相结合就产生了GTID，即GTID=server_uuid：transaction_id。

我们也许会好奇，主、从服务器之间是如何约定这个神奇的GTID的，这就要谈谈GTID在主、从服务器间的交互了。当主服务器上成功执行并提交了一个事务的时候，主服务器会为这个事务分配一个尚不存在的最小的非0序号，也就是transaction_id，从而生成GTID。

从服务器会将请求到的Binlog信息放到自己的Relay-log中，在应用这条Binlog时，会对该条Binlog的GTID值加一个特权，表明从服务器执行的下一个事务必须使用这一GTID值，而从服务器将要执行的就是请求到的Binlog中的事务行为，这样就保证了全局环境中同一个事务的GTID不变。

也就是说GTID足以标明全局中的每条Binlog信息，这就带来了另一大好处，从服务器不会把同一条Binlog信息重复执行，保证数据复制的正确性。

从服务器怀揣着翻身做主的梦，恪尽职守，然而现实太残酷，上演了一幕壮志未酬身先死，是的，从服务器宕机了。我们当然会将从服务器拯救回来，但这需要时间啊，在这段宝贵的时间里，主服务器是不会停止前进的脚步的，Binlog信息仍在持续增加，那么重获新生的从服务器又该如何快速追上主服务器的步伐？

幸好有GTID的存在，能让从服务器立马明白自己和主服务器的差距，从正确的点位开始追赶，用不了多久，就又与主服务器数据一致了。

三、MySql主从复制原理及配置

转自：https://juejin.im/post/5e1daba46fb9a02fb75d5e92

仅做个人备份，浏览请看原文

什么是主从复制？

主从复制是指将主数据库的DDL和DML操作通过二进制日志传到从数据库上，然后在从数据库上对这些日志进行重新执行，从而使从数据库和主数据库的数据保持一致。

主从模式优点

▲支持读写分离，降低数据库负荷。

通常情况下，会使用主服务器对数据进行更新、删除和新建等操作，而将查询工作落到从库头上。

▲异地灾备。

可以将主服务器上的数据同步到异地从服务器上，极大地提高了数据安全性。

▲提高数据库系统的可用性。

数据库的复制功能实现了主服务器与从服务器间的数据同步，一旦主服务器出了故障，从服务器立即担当起主服务器的角色，保障系统持续稳定运作。

主从复制的原理

MySql主库在事务提交时会把数据变更作为事件记录在二进制日志Binlog中；
主库推送二进制日志文件Binlog中的事件到从库的中继日志Relay Log中，之后从库根据中继日志重做数据变更操作，通过逻辑复制来达到主库和从库的数据一致性；
MySql通过三个线程来完成主从库间的数据复制，其中Binlog Dump线程跑在主库上，I/O线程和SQL线程跑着从库上；
当在从库上启动复制时，首先创建I/O线程连接主库，主库随后创建Binlog Dump线程读取数据库事件并发送给I/O线程，I/O线程获取到事件数据后更新到从库的中继日志Relay Log中去，之后从库上的SQL线程读取中继日志Relay Log中更新的数据库事件并应用，如下图所示。

主实例搭建

运行mysql主实例：

docker run -p 3307:3306 --name mysql-master -v /mydata/mysql-master/log:/var/log/mysql -v /mydata/mysql-master/data:/var/lib/mysql -v /mydata/mysql-master/conf:/etc/mysql -e MYSQL_ROOT_PASSWORD=root -d mysql:5.7
复制代码
在mysql的配置文件夹/mydata/mysql-master/conf中创建一个配置文件my.cnf：

touch my.cnf
复制代码
修改配置文件my.cnf，配置信息如下：

[mysqld]

设置server_id，同一局域网中需要唯一

server_id=101

指定不需要同步的数据库名称

binlog-ignore-db=mysql

开启二进制日志功能

log-bin=mall-mysql-bin

设置二进制日志使用内存大小（事务）

binlog_cache_size=1M

设置使用的二进制日志格式（mixed,statement,row）

binlog_format=mixed

二进制日志过期清理时间。默认值为0，表示不自动清理。

expire_logs_days=7

跳过主从复制中遇到的所有错误或指定类型的错误，避免slave端复制中断。

如：1062错误是指一些主键重复，1032错误是因为主从数据库数据不一致

slave_skip_errors=1062
复制代码
修改完配置后重启实例：

docker restart mysql-master
复制代码
进入mysql-master容器中：

docker exec -it mysql-master /bin/bash
复制代码
在容器中使用mysql的登录命令连接到客户端：

mysql -uroot -proot
复制代码
创建数据同步用户：

CREATE USER 'slave'@'%' IDENTIFIED BY '123456';
GRANT REPLICATION SLAVE, REPLICATION CLIENT ON . TO 'slave'@'%';
复制代码

从实例搭建

运行mysql从实例：

docker run -p 3308:3306 --name mysql-slave -v /mydata/mysql-slave/log:/var/log/mysql -v /mydata/mysql-slave/data:/var/lib/mysql -v /mydata/mysql-slave/conf:/etc/mysql -e MYSQL_ROOT_PASSWORD=root -d mysql:5.7
复制代码
在mysql的配置文件夹/mydata/mysql-slave/conf中创建一个配置文件my.cnf：

touch my.cnf
复制代码
修改配置文件my.cnf：

[mysqld]

设置server_id，同一局域网中需要唯一

server_id=102

指定不需要同步的数据库名称

binlog-ignore-db=mysql

开启二进制日志功能，以备Slave作为其它数据库实例的Master时使用

log-bin=mall-mysql-slave1-bin

设置二进制日志使用内存大小（事务）

binlog_cache_size=1M

设置使用的二进制日志格式（mixed,statement,row）

binlog_format=mixed

二进制日志过期清理时间。默认值为0，表示不自动清理。

expire_logs_days=7

跳过主从复制中遇到的所有错误或指定类型的错误，避免slave端复制中断。

如：1062错误是指一些主键重复，1032错误是因为主从数据库数据不一致

slave_skip_errors=1062

relay_log配置中继日志

relay_log=mall-mysql-relay-bin

log_slave_updates表示slave将复制事件写进自己的二进制日志

log_slave_updates=1

slave设置为只读（具有super权限的用户除外）

read_only=1
复制代码
修改完配置后重启实例：

docker restart mysql-slave
复制代码

将主从数据库进行连接

连接到主数据库的mysql客户端，查看主数据库状态：

show master status;
复制代码
主数据库状态显示如下：

进入mysql-slave容器中：

docker exec -it mysql-slave /bin/bash
复制代码
在容器中使用mysql的登录命令连接到客户端：

mysql -uroot -proot
复制代码
在从数据库中配置主从复制：

change master to master_host='192.168.6.132', master_user='slave', master_password='123456', master_port=3307, master_log_file='mall-mysql-bin.000001', master_log_pos=617, master_connect_retry=30;
复制代码
主从复制命令参数说明：
- master_host：主数据库的IP地址；
- master_port：主数据库的运行端口；
- master_user：在主数据库创建的用于同步数据的用户账号；
- master_password：在主数据库创建的用于同步数据的用户密码；
- master_log_file：指定从数据库要复制数据的日志文件，通过查看主数据的状态，获取File参数；
- master_log_pos：指定从数据库从哪个位置开始复制数据，通过查看主数据的状态，获取Position参数；
- master_connect_retry：连接失败重试的时间间隔，单位为秒。
查看主从同步状态：

show slave status \G;
复制代码
从数据库状态显示如下：