MySQL 主从配置（主从延迟、主库宕机处理）

主库 地址：192.168.0.1 数据库用户：root 数据库密码 ******
从库 地址：192.168.0.2 数据库用户: slave01 数据库密码 ******

1、同步主从数据库的数据，使用navicat 工具进行数据传输

image.png

2、修改主服务器master

vim /etc/my.cnf

[mysqld]
log-bin=mysql-bin   //[必须]启用二进制日志
server-id=61      //[必须]服务器唯一ID，默认是1，一般取IP最后一段

3、修改从服务器slave:

[mysqld]
log-bin=mysql-bin   //[不是必须]启用二进制日志
server-id=1      //[必须]服务器唯一ID，默认是1，一般取IP最后一段   

4、重启两台服务器的mysql

5、在主服务器上建立帐户并授权slave:

a、创建用户：

CREATE USER 'slave01'@'%' IDENTIFIED BY '123456'; 

b、在主服务器上授权slave:

GRANT REPLICATION SLAVE ON *.* to 'slave01'@'%' identified by '123456';

6、登录主服务器的mysql，查询master的状态

show master status;

+------------------+----------+--------------+------------------+
| File | Position | Binlog_Do_DB | Binlog_Ignore_DB |
+------------------+----------+--------------+------------------+
| mysql-bin.000004 | 308 | | |
+------------------+----------+--------------+------------------+
1 row in set (0.00 sec)

7、配置从服务器Slave：

change master to master_host='192.168.0.1',master_user='slave01',master_password='123456',master_log_file='mysql-bin.000006',master_log_pos=16363218;   
    //注意不要断开，308数字前后无单引号。
    //master_host是主服务器的ip
    //mstert_user是第5步在主服务器上建立的账号用户名
    //master_passowrd是第5步在主服务器上建立的账号密码
    //master_log_file是第6步在主服务器上查询出来的表格中的第一个字段
    //master_log_pos是第6步在主服务器上查询出来的表格中的第二个字段

8、 启动从服务器复制功能

start slave;

9、检查从服务器复制功能状态：

show slave status\G

   *************************** 1. row ***************************

              Slave_IO_State: Waiting for master to send event
              Master_Host: 192.168.2.222  //主服务器地址
              Master_User: username   //授权帐户名，尽量避免使用root
              Master_Port: 3306    //数据库端口，部分版本没有此行
              Connect_Retry: 60
              Master_Log_File: mysql-bin.000004
              Read_Master_Log_Pos: 600     //#同步读取二进制日志的位置，大于等于 
              Exec_Master_Log_Pos
              Relay_Log_File: ddte-relay-bin.000003
              Relay_Log_Pos: 251
              Relay_Master_Log_File: mysql-bin.000004
              Slave_IO_Running: Yes    //此状态必须YES
              Slave_SQL_Running: Yes     //此状态必须YES
                    ......

10、开始测试

11、主从延迟解决

MySQL 5.6中，设置参数slave_parallel_workers = 4(>1)，即可有4个SQL Thread（coordinator线程）来进行并行复制，其状态为：Waiting for an evant from Coordinator。但是其并行只是基于Schema的，也就是基于库的。如果数据库实例中存在多个Schema，这样设置对于Slave复制的速度可以有比较大的提升。通常情况下单库多表是更常见的一种情形，那基于库的并发就没有用。其核心思想是：不同数据库下的表并发提交时的数据不会相互影响，即slave节点可以用对relay log中不同的schema各分配一个类似SQL功能的线程，来重放relay log中主库已经提交的事务，保持数据与主库一致。

在MySQL 5.7中，引入了基于组提交的并行复制（Enhanced Multi-threaded Slaves），设置参数slave_parallel_workers>0并且global.slave_parallel_type＝‘LOGICAL_CLOCK’，即可支持一个数据库下，slave_parallel_workers个的worker线程并发执行relay log中主库提交的事务。其核心思想：一个组提交的事务都是可以并行回放（配合binary log group commit）；slave机器的relay log中last_committed相同的事务（sequence_num不同）可以并发执行。其中，变量slave-parallel-type可以有两个值：DATABASE 默认值，基于库的并行复制方式；LOGICAL_CLOCK：基于组提交的并行复制方式

 slave-parallel-type=LOGICAL_CLOCK
 slave-parallel-workers=16
 master_info_repository=TABLE
 relay_log_info_repository=TABLE
 relay_log_recovery=ON

12、主库宕机数据丢失问题

一 、异步、同步和半同步复制概念
　　异步复制（Asynchronous replication），MySQL默认的复制是异步的，主库在执行完客户端提交的事务后会立即将结果返给给客户端，并不关心从库是否已经接收并处理。原理最简单，性能最好，但是主从之间数据不一致的概率很大。
　　全同步复制（Fullysynchronous replication），指当主库执行完一个事务，所有的从库都执行了该事务才返回给客户端。因为需要等待所有从库执行完该事务才能返回，所以全同步复制的性能必然会收到严重的影响。
　　半同步复制（Semisynchronous replication），介于异步复制和全同步复制之间，主库在执行完客户端提交的事务后不是立刻返回给客户端，而是等待至少一个从库接收到并写到relay log中才返回给客户端。相对于异步复制，半同步复制牺牲了一定的性能，提高了数据的安全性。

二、半同步复制原理

默认情况下，MySQL的主从复制是异步的，异步复制可以提供最佳的性能， 主库把binlog日志发送给从库，然后将结果返回给客户端，并不会验证从库是否接收完毕。这也就意味着有可能出现当主库或从库发生故障的时候，从库没有接收到主库发送过来的binlog日志，导致主库和从库的数据不一致，甚至在恢复时造成数据的丢失。

为了解决上述出现的问题，MySQL 5.5 引入了一种半同步复制模式。该模式可以确保从库接收完主库发送的binlog日志文件并写入到自己的中继日志relay log里，然后会给主库一个反馈，告诉主库已经接收完毕，这时主库才返回结果给客户端告知操作完成。当出现从库响应超时情况时，主库会暂时切换到异步复制模式，直到下一次同步没有超时转为半同步复制为止。（master的dump线程除了发送binlog数据到slave，还承担了接收slave的ack工作。如果出现异常，没有收到ack，那么将自动降为普通的异步复制，直到异常修复）

三、半同步复制--MySQL5.7版

MySQL5.5半同步复制带来的新问题：

1）如果有故障发生，会切换为异步的复制。 那么从库出现数据不一致的几率会减少，并不是完全消失。

2）主机dump线程承担的工作变多了（发送binlog数据到slave，接收slave的ack。两者是串行的，dump线程必须等待slave返回ack之后才会传送下一个events事务。dump线程是整个半同步提高性能的瓶颈），这样显然会降低整个数据库的性能。

3）在MySQL 5.5和5.6使用after_commit的模式下, 如果slave没有收到事务，也就是还没有写入到relay log之前，网络出现异常或者不稳定，此时刚好master挂了，系统切换到从库，两边的数据就会出现不一致，slave会少一个事务的数据。在此情况下，MySQL5.7的半同步复制技术升级为全新的Loss-less Semi-Synchronous Replication架构，新版本的semi sync增加了rpl_semi_sync_master_wait_point参数, 来控制半同步模式下主库在返回结果给会话之前提交事务的方式。

该参数有两个值：

1）AFTER_COMMIT（5.5，5.6默认值）
　　master将每个事务写入binlog之后，先提交事务，然后将binlog数据传递到slave并刷新到磁盘(relay log)。接着master等待slave反馈收到relay log，只有收到ack之后master才将commit OK结果反馈给客户端。
2）AFTER_SYNC（5.7默认值）
　　master将每个事务写入binlog，然后将binlog数据传递到slave并刷新到磁盘(relay log)。master等待slave反馈接收到relay log的ack之后，再提交事务并且返回commit OK结果给客户端。即使主库crash了，所有在主库上已经提交的事务都能保证已经同步到slave的relay log中。
　　MySQL5.7的半同步复制引入after_sync模式，主要是解决了after_commit导致的主库crash后主从之间数据不一致的问题。在引入after_sync模式后，所有提交的数据都已经被复制，故障切换时数据一致性将得到提升。（另外，在5.7版本的semi sync框架中，独立出一个ack collector thread，专门用于接收slave的反馈信息。这样master上有两个线程独立工作，可以同时发送binlog到slave，和接收slave的反馈）
四、半同步复制配置

分别在主从库加载上面两个插件

master:

mysql> install plugin rpl_semi_sync_master soname 'semisync_master.so';

slave:

mysql> install plugin rpl_semi_sync_slave soname 'semisync_slave.so';

查看是否安装成功

show plugins;

配置文件

#主库
plugin-load = rpl_semi_sync_master=semisync_master.so  #此项可以让plugin在任何时候都被mysql加载
rpl_semi_sync_master_enabled = 1
#从库
plugin-load = rpl_semi_sync_slave=semisync_slave.so
rpl_semi_sync_slave_enabled = 1
#或者，在有的高可用架构下master和slave需同时启动，以便在切换后能继续使用半同步复制
plugin-load = "rpl_semi_sync_master=semisync_master.so;rpl_semi_sync_slave=semisync_slave.so"
rpl-semi-sync-master-enabled = 1
rpl-semi-sync-slave-enabled = 1

重启slave上的IO线程使半同步生效，如果没有重启，则默认还是异步复制，重启后，slave会在master上注册为半同步复制的slave角色。

mysql> stop slave io_thread;
mysql> start slave io_thread;
#master：查看半同步是否在运行
mysql> show status like 'Rpl_semi_sync_master_status';
#slave：查看半同步是否在运行
mysql> show status like 'Rpl_semi_sync_slave_status';

其他说明

1）环境变量

mysql> show variables like '%semi%';
+------------------------------------+-------+
| Variable_name | Value |
+------------------------------------+-------+
| rpl_semi_sync_master_enabled | ON |
| rpl_semi_sync_master_timeout | 10000 |
| rpl_semi_sync_master_trace_level | 32 |
| rpl_semi_sync_master_wait_no_slave | ON |
+------------------------------------+-------+
4 rows in set (0.00 sec)

rpl_semi_sync_master_enabled=ON 表示开启半同步复制
rpl_semi_sync_master_timeout=10000 单位为毫秒，即10秒超时，将切换为异步复制
rpl_semi_sync_master_wait_no_slave 表示是否允许master每个事务都要等待slave接收确认。默认为ON，每一个事务都会等待，如果slave crash后，当slave追赶上master的日志时，可以自动的切换为半同步方式。如果为OFF,则slave追赶上后，也不会采用半同步的方式复制了，需要手工配置。
rpl_semi_sync_master_trace_level=32 表示用于开启半同步复制时的调试级别，默认32
rpl_semi_sync_master_wait_for_slave_count MySQL 5.7.3引入的，该变量设置主库需要等待多少个slave应答，才能返回给客户端，默认为1。
2）状态变量
mysql> show status like '%semi%';
+--------------------------------------------+-------+
| Variable_name | Value |
+--------------------------------------------+-------+
| Rpl_semi_sync_master_clients | 0 | #记录支持半同步的slave的个数
| Rpl_semi_sync_master_net_avg_wait_time | 0 | #master 等待slave回复的平均等待时间，单位微秒
| Rpl_semi_sync_master_net_wait_time | 0 | #master 总的等待时间
| Rpl_semi_sync_master_net_waits | 0 | #master 等待slave回复的的总的等待次数
| Rpl_semi_sync_master_no_times | 0 | #master 关闭半同步复制的次数
| Rpl_semi_sync_master_no_tx | 0 | #master 没有收到slave的回复而提交的次数
| Rpl_semi_sync_master_status | OFF | #标记master现在是否是半同步复制状态
| Rpl_semi_sync_master_timefunc_failures | 0 | #时间函数未正常工作的次数
| Rpl_semi_sync_master_tx_avg_wait_time | 0 | #开启Semi-sync，事务返回需要等待的平均时间
| Rpl_semi_sync_master_tx_wait_time | 0 | #事务等待备库响应的总时间
| Rpl_semi_sync_master_tx_waits | 0 | #事务等待备库响应的总次数
| Rpl_semi_sync_master_wait_pos_backtraverse | 0 | #改变当前等待最小二进制日志的次数
| Rpl_semi_sync_master_wait_sessions | 0 | #当前有多少个session 因为slave 的回复而造成等待
| Rpl_semi_sync_master_yes_tx | 0 | #master 成功接收到slave的回复的次数
+--------------------------------------------+-------+
（注：status中rpl相关的时间单位是微秒）