MySQL主从复制与切换

1.主从架构及基本原理

常见主从部署架构：一主多从、一丛多主、双主复制、主从级联复制。

1.1主从复制原理

1.从节点开启start slave，开启主从复制，从节点IO线程与主节点建立连接，请求数据同步；
2.主节点接收到从节点的数据请求，针对该从节点建立单独的log dump线程，将数据返回给从节点；
3.从节点接收到主节点发送过来的binlog之后，会将binlog追加到rely log后面，并保存已处理过的binlog位置
4.从节点的sql线程检测到rely log内容有变化，会将rely log追加的内容解析成sql，然后执行sql；

1.2主从复制涉及线程

MySQL主从复制主要涉及三个线程，一个在源两个在副本：

binary log dump thread （二进制日志转储线程）：当副本连接到源时，源创建这个线程将二进制内容发送到副本。在源上使用show processlist查看时，该线程被标识为Binlog Dump线程。
replication I/O thread（复制IO线程）：在副本上发出START REPLICA语句时，副本创建一个IO线程，该线程连接到源并要求它发送其二进制日志中记录的更新。复制IO线程接收到源的二进制日志的更新，并将其保存到副本的中继日志文件中。在show slave status的输出中，该线程的状态显示为Slave_IO_running
Replication IO thread（复制sql线程）：副本创建的SQL线程来读取复制IO线程写入的中继日志，并执行其中包含的事务。把系统参数replica_parallel_workers设置为大于0时，会有指定相同数量的工作线程并行执行SQL线程的工作和一个协调线程协调这些工作线程

1.3主从同步三种模式

异步复制：主节点将数据写入到binlog，提交事务后就立即返回给客户端，不关心binlog是否同步到从节点
半同步复制：binlog至少同步给一个从节点之后就返回给客户端成功
全同步复制：binlog需要成功同步给所有从节点之后才返回给客户端成功

1.4binlog格式

ROW：行，记录某一条记录被修改成了什么样子，只需要记录修改后的所有字段细节，可能导致产生大量日志影响同步效率
Statement：语句，只记录执行的SQL，日志量小，但对于某些函数（now()等可能存在重放值不一样导致主从数据不一致
MIXED：混合，MySQL智能判断时使用statement还是row格式，默认修改采用statement模式，如果statement模式无法保证主从复制的一致性，则采用ROW模式

通过配置参数binlog_format决定：

mysql>show variables like 'binlog_format';
+-----------------+---------+
|  Variable_name  |  Value  |
+-----------------+---------+
|  binlog_format  |  Row    |
+-----------------+---------+

2.主从搭建

主从搭建需要保证主库和从库的server_id不一样，主库必须要开启二进制日志（log_bin为ON），同时开启gtid，设置enforce_gtid_consistency=1。

mysql>show variables like 'log_bin';
+----------------+---------+
|  Variable_name |  Value  |
+----------------+---------+
|  log_bin       |  ON     |
+----------------+---------+

主库上创建用于主从复制的账号：

mysql>create user 'reg'@'%' identified by 'a123456';
Query OK, 0 rows affected (0.02 sec)

给账号授予复制权限：

mysql> grant replication slave on *.* to 'reg'@'%';
Query OK, 0 rows affected (0.01 sec)

从库上执行：

mysql> change master to master_host='10.453.63.5',master_port_3306,master_user='reg',master_password='a123456',master_auto_position=1;
Query OK, 0 rows affected, 2 warnings (0.02 sec)

从库上开启同步：

mysql> start slave;

查看从库状态，如果Slave_IO_Running和Slave_SQL_Running两个状态都为Yes，则表示主从同步正常。

mysql> show slave status\G

3.主从复制重要参数

mysql> show slave status\G
*************************** 1. row ***************************Slave_IO_State: Waiting for master to send event --IO thread的状态Master_Host: 10.95.253.241       -- 主库ip     Master_User: repl                -- 用于连接主库复制账号（这个账号是在主库上创建）Master_Port: 3300                -- 主库端口 Connect_Retry: 10                  -- 连接重试的秒数（默认 60）Master_Log_File: mysql-bin.005395    -- I/O 线程当前正在读取的主库的二进制日志文件名称。Read_Master_Log_Pos: 684976832           -- I/O 线程已读取的当前主库二进制日志文件中的位点Relay_Log_File: dd-relay.000063     -- SQL线程正在读取和执行的中继日志名称Relay_Log_Pos: 684953253           -- SQL线程正在读取和执行的当前中继日志的位点Relay_Master_Log_File: mysql-bin.005395    -- SQL 线程执行的最新事件 对应在主库上的二进制日志文件名称。Slave_IO_Running: Yes                 -- IO线程是否已启动并已成功连接到主库Slave_SQL_Running: Yes                 -- SQL线程是否启动。Replicate_Do_DB:                     -- 需要复制的DBReplicate_Ignore_DB:                     -- 复制忽略的DBReplicate_Do_Table:                     -- 需要复制的表Replicate_Ignore_Table:                     -- 复制忽略的表Replicate_Wild_Do_Table:                     -- 用于指定需要复制的数据库表，支持通配符（wildcard）的形式Replicate_Wild_Ignore_Table:                     -- 用于指定需要忽略（不复制）的数据库表，同样支持通配符的形式。Last_Errno: 0                   -- Last_SQL_Errno的别名Last_Error:                     -- Last_SQL_Error的别名Skip_Counter: 0                   -- 系统变sql_slave_skip_counter 的当前值  （从库跳过的SQL数量）Exec_Master_Log_Pos: 684953080           -- SQL线程已经读取和执行过的中继日志 对应在主库二进制日志文件的位点Relay_Log_Space: 684977292           -- 所有现有中继日志文件的总大小。Until_Condition: None                -- start slave 中制定 until 语句Until_Log_File:                     -- start slave 中制定 until 语句Until_Log_Pos: 0                   -- start slave 中制定 until 语句Master_SSL_Allowed: No                  -- 是否允许与源的 SSL 连接Master_SSL_CA_File:                     -- 指定用于验证主服务器证书的证书颁发机构（CA）文件的路径Master_SSL_CA_Path:                     -- 指定用于验证主服务器证书的证书颁发机构（CA）路径的路径Master_SSL_Cert:                     -- 指定从服务器的 SSL 证书文件的路径Master_SSL_Cipher:                     -- 指定在 SSL 通信中使用的密码套件Master_SSL_Key:                     -- 指定从服务器的 SSL 私钥文件的路径Seconds_Behind_Master: 0                   -- 主从延迟
Master_SSL_Verify_Server_Cert: No                  -- 表示是否验证主服务器的 SSL 证书。Last_IO_Errno: 0                   -- 导致IO线程停止的最近一次的错误码，Errno :0 表示表示没有错误Last_IO_Error:                     -- 导致IO线程停止的最近的错误信息 。Erro为空表示没有错误 Last_SQL_Errno: 0                   -- 导致SQL线程停止的最近的错误码。Errno :0 表示没有错误 Last_SQL_Error:                     -- 导致SQL线程停止的错误信息,Erro为空表示没有错误 Replicate_Ignore_Server_Ids:                     -- 忽略复制的主库的server_idMaster_Server_Id: 181323300           -- 主库的参数server_id的值Master_UUID: 127ef593-1826-11eb-8a97-6c92bf7d39de           -- 主库参数server_uuid的值Master_Info_File: mysql.slave_master_info                        -- 在从库上存储主库信息的文件或表SQL_Delay: 0                                              -- 从库延迟主库多少秒SQL_Remaining_Delay: NULL                                           -- 当Slave_SQL_Running_State为 时 Waiting until MASTER_DELAY seconds after master executed event，该字段包含剩余延迟秒数。其他时候，该字段为 NULL。Slave_SQL_Running_State: Slave has read all relay log; waiting for more updates -- SQL线程的运行状态Master_Retry_Count: 86400  -- 在连接丢失的情况下，从库可以尝试重新连接到主库的次数。Master_Bind:       -- Last_IO_Error_Timestamp:       -- 最近的I/O 线程发生错误的时间 格式YYMMDD hh:mm:ssLast_SQL_Error_Timestamp:       -- 最近的SQL 线程发生错误的时间 格式YYMMDD hh:mm:ssMaster_SSL_Crl:       -- 指定撤销列表 (CRL) 文件的路径，该文件包含已被撤销的 SSL 证书列表Master_SSL_Crlpath:       -- 指定撤销列表 (CRL) 文件的路径，该文件包含已被撤销的 SSL 证书列表Retrieved_Gtid_Set: 127ef593-1826-11eb-8a97-6c92bf7d39de:330411-2764671 -- 从库已经接收到的GTID的集合（I/O线程），如果GTID模式没有开启则为空。这个值是现在存在或者已经存在在relay log中的GTID集合 Executed_Gtid_Set: 127ef593-1826-11eb-8a97-6c92bf7d39de:1-2764671,
3133d0b5-8d65-11e7-9f2e-c88d83a9846a:1-12697883,
657b7d6b-8d60-11e7-b85f-6c92bf4e09e6:1-1661102840    -- 已经被写进binlog的GTID的集合（SQL线程），这个值和 系统参数 gtid_executed 相同。也和在该实例上执行 show master status 中的Executed_Gtid_Set 值相同Auto_Position: 1  -- 如果正在使用自动定位1；否则为 0。Replicate_Rewrite_DB:    -- 用于指定需要在主从复制过程中进行数据库名重写的规则。Channel_Name:    -- 正在显示的复制通道Master_TLS_Version:    -- 源上使用的 TLS 版本

4.主从延迟

4.1主从延迟产生原因

为了完成主从复制，从库需要通过 I/O 线程获取主库中 dump 线程读取的 binlog 内容并写入到自己的中继日志 relay log 中，从库的 SQL 线程再读取中继日志，重做中继日志中的日志，相当于再执行一遍 SQL，更新自己的数据库，以达到数据的一致性。

与数据同步有关的时间点主要包括以下三个：
主库执行完一个事务，写入 binlog，将这个时刻记为 T1；
之后传给从库，将从库接收完这个 binlog 的时刻记为 T2；
从库执行完成这个事务，将这个时刻记为 T3。
所谓主从延迟，就是同一个事务，从库执行完成的时间与主库执行完成的时间之差，也就是 T3 - T1。

MySQL的主从复制都是单线程的操作，主库对所有DDL和DML产生的日志写进binlog，由于binlog是顺序写，所以效率很高。Slave的SQL Thread线程将主库的DDL和DML操作事件在slave中重放。DML和DDL的IO操作是随即的，不是顺序的，成本高很多。另一方面，由于SQL Thread也是单线程的，当主库的并发较高时，产生的DML数量超过slave的SQL Thread所能处理的速度，或者当slave中有大型query语句产生了锁等待那么延时就产生了。

4.2 导致问题

1.如果是读写分离的系统，从库延时过高会导致数据不一致，导致读取数据有误
2.如果主从延时时间超过主库binlog保留时间，从库将产生数据丢失
3.主从延迟过大,会影响数据库的高可用切换

4.3 解决方案

分析主从延迟的原因
主从延迟的原因可能有多种，包括网络延迟、硬件故障、复制线程阻塞等。我们需要深入分析这些原因，并评估它们对主从延迟的影响程度。例如，网络延迟可能是最常见的原因之一，我们可以通过优化网络配置、使用更快的网络设备等方式来减少网络延迟。
监测主从延迟
为了及时发现和解决主从延迟问题，我们需要监测主从延迟的情况。常用的监测方法和工具包括Percona Toolkit和pt-heartbeat等。这些工具可以帮助我们设置监测阈值和触发警报的机制，以便及时采取措施。
优化主从复制配置
优化主从复制的配置可以帮助我们减少主从延迟。

# 增加以下配置项，启用并行复制
slave_parallel_type = LOGICAL_CLOCK
slave_parallel_workers = 8