MySQL主从复制集群

小鱼儿 2022-05-25 11:47 246阅读 0赞

*  `MySQL`的日志包括:事务日志,错误日志,一般查询日志,中继日志,慢查询日志
 *  二进制日志:
    
     *  一般在数据目录里面,通常格式为`mysql-bin.xxxxxx`日志会执行滚动操作:当日志大小达到最大上限时,或者执行`FLUSH LOGS`,或者服务器重新启动时;
     *  二进制日志的格式:`statement row mixed`;
     *  查看当前使用的二进制日志:`SHOW MASTER STATUS;`
     *  查看当前使用的二进制日志索引:`SHOW BINARY LOGS;`
     *  查看当前二进制日志的具体事件:`SHOW BINLOG EVENTS IN | BEFORE 'file';`
 *  二进制日志记录的事件内容包括:`timestamp postion events`
 *  二进制日志用于即时点还原:在完全使用二进制日志在进行数据内容的恢复过程中,和原始数据不一定是一样的,存在以下几点原因:
    
     *  1.多`CPU`的`MySQL`服务器,可能会支持多事务,或者在事务的隔离级别影响下交叉执行,或者是并行执行,但是对于二进制日志文件只有一个,向文件里面写入内容都是串行的;
     *  2.二进制日志文件并不能够保证和原始数据库的数据文件绝对的处于一致状态;
 *  一种情况就是使用事务的隔离级别为`REPEATABLE-READ`并且二进制日志的记录格式为`STATEMENT`,会导致数据不一致的可能性变大;
 *  还有一种情况是:二进制日志的隔离级别为`READ-UNCOMMITTED READ-COMMITTED`,并且二进制日志的记录格式为`MIXED`,也会导致数据不一致的可能性变大;
 *  `statement`的格式的日志记录格式不建议使用;
 *  关于主从复制的原理:
 *  服务器`A`接受前端用户的写入操作,这些写操作首先会被写入二进制日志文件中,并且一份写入数据文件;
 *  服务器`B`不接受任何前端用户的写操作,但是实时同步服务器`A`的二进制日志文件,首先保存在自己的二进制日志文件里面,并且按照一定的时间读取里面的内容写入数据文件;
 *  服务器`A`称为`master`,其二进制日志是由于数据的写入操作导致的;
 *  服务器`B`称为`slave`,其二进制日志称为中继日志`relay log`,这些日志不是由于自己的写入操作导致的,而是同步过来的日志文件进行重放;
 *  `slave`的数据写入肯定是慢于`master`的,很可能由于`master`和`slave`的服务器性能差异太多,导致数据差异更大;
 *  关于数据同步的三种模型:同步,异步,半同步;
    
     *  异步:`MySQL`默认的同步策略是异步的,保证数据写入的速度,数据写入本地的二进制日志,并且写入磁盘设备,就认为写入完成;
     *  半同步:数据需要保存在`TCP/IP`的缓冲区里面,主从架构中的从节点中只要一个从节点返回数据保存成功,就认为数据已经保存成功,`MySQL 5.5`通过补丁可以支持半同步,之前的版本都是不支持的,在一主多从的架构下,只要有一个结点返回数据插入成功,那么就认为数据插入完成;
     *  同步:主从服务器的速度是一致的,导致数据插入困难,这个方式是不建议的;这个方式数据需要在从服务器上面完成数据的写入操作,才认为数据插入是成功的;
 *  `MySQL`服务器允许一主多从架构,所以异步同步策略是最佳同步策略,从服务器可以用于保证查询的效率,并且可以用于进行备份;从服务器需要备份的时候,如果需要进行即时点还原,需要的是主服务器的二进制日志,而不是从服务器的中继日志;
 *  中继日志的格式和二进制日志格式是一致的,但是主服务器的二进制日志滚动,从服务器的二进制日志是不一定滚动的;例如`FLUSH LOGS`,主服务器重新启动等;
 *  `slave`服务器是否需要二进制日志:
    
     *  如果不需要:因为简单的主从架构,二进制日志的内容和中继日志的内容几乎是一样的,所以可以不需要;
     *  但是对于多级主从架构,二进制日志是必须进行记录的`A---->B----->C`,`A`的二进制日志传递给`B`,`B`生成中继日志,但是`B`的中继日志不能够直接给`C`,所以`B`是需要记录二进制日志的;
 *  如果主服务器宕机,从服务器需要执行完主服务器上面产生的未同步过来的二进制日志,并且修改权限为可写,这样快速的执行故障恢复,可以提供类似于高可用的功能;
 *  不能够把中继日志当作数据恢复的手段,必须使用主服务器的二进制日志来进行还原;
 *  并且可以用于实现异地容灾;
 *  最主要的功能是用于实现分摊负载,通常来说是读多写少,用于实现读写分离,通常来说读写分离需要通过前端的`MySQL Proxy`代理来实现,这个代理成为`rw-spliting`,这个读写分离代理必须理解前端的语句,代理并不能够实现读写分离,可以再代理和`MySQL`服务器之间进行`Directory`的实现负载均衡;
 *  多个读服务器可以通过`Memory Cache`来实现缓存共享,或者使用`MySQL`自己的缓存,并且结合持久连接;
 *  如果主从架构采用简单的架构进行复制,那么`master`就需要为每一个`slave`创建复制线程,负载仍然较大,所以这里需要使用多级复制,减轻`master`的负担;
 *  修改后的主从复制架构  
    ![这里写图片描述][70]
 *  对于第二个节点:
    
     *  1.首先需要启动多个线程来将二进制日志同步给其余的`master`节点;
     *  2.其次,第二个节点需要多个线程来负责中继日志的处理,这个节点就不应该处理读请求,这个节点既不处理读请求,也不处理写请求,但是需要通过写入数据的操作来产生二进制日志,这里就需要使用特殊的存储引擎`BLACK_HOLL`存储引擎,通过这个机制可以减轻节点`IO`处理压力;  
        ![这里写图片描述][70 1]
 *  在`MySQL`服务器架构中,不适用`MySQL` 代理,如何实现主写从读,这个功能可以交给`PHP`连接`MySQL`的应用程序来解决,通过制定主服务器和从服务器来实现读写分离,但是这种方法也存在缺点,会破坏负载均衡,因为制定的算法都是各自进行调度的;
 *  如果不想通过上述两种办法来解决,那么就可以通过`MySQL`的双主模型来解决,但是不建议使用这种方式,因为性能低下;
 *  **双主模型的工作原理**  
    ![这里写图片描述][70 2]
 *  上述模型可能出现的问题:  
    \* 由于数据中继日志写入,会更新二进制日志,然后二进制日志会在另一个服务器上面执行,生成新的二进制日志,这样会导致无限循环;  
    \* 对于上面的问题需要引入服务器`ID`用于标示语句的执行情况,对于中继日志执行的写入操作,是必须写入自己的二进制日志文件里面的,因为一旦这个`master`作为了`slave`的`master`,二进制就是不完善的 ,所以`server ID`为对方`ID`的是必须写入二进制日志的;
 *  二进制日志中的格式会记录这个问题
 *  双主模型是可以分担的是读负载,但是不能够分担写负载;
 *  双主模型可能出现下面的问题:  
    ![这里写图片描述][70 3]
 *  会因为更新特殊的数据导致数据不一致无法合并的问题;
 *  主键使用的增长导致的主键冲突的问题;
 *  当数据库的内容十分庞大时,查询,写入速度十分缓慢时,可以采用拆库的策略,将各个库独立出来,用于减轻服务器的压力;
 *  垂直拆分:将一个库拆分为多个库,数据库存在数据热区的,有时候是某张表的频繁查询减低了查询速度;
 *  水平拆分:可以将表进行拆分;
 *  在执行水平拆分以及垂直拆分之后,当查询的操作涉及多个表,并且需要将这些表的数据整合返回时,就需要借助于`MySQL`路由设备 ,用于完成上述操作;
 *  数据的插入操作需要按照拆分表时的逻辑,来执行数据的的插入负载均衡,而不是统一在某个服务器上面完成操作;
 *  数据库的拆分,需要理解业务逻辑,根据业务来进行拆分,
 *  **MySQL多主模型的循环复制 需要解决**
 *  读写分离的工具:`MySQL -proxy amoba cobar(业务逻辑拆分工具)`
 *  配置`MySQL`的主从复制架构:
 *  通常是一个`master`多个`slave`架构,但是不能够一`slave`多个`master`;
 *  `MySQL 5.5`之前的版本:复制功能比较简单,但是在`MySQL 5.6`之后引入了`gtid[全局事务号]`,以及`multi-thread replcation`\[多线程复制\];
 *  **MySQL 5.5主从服务的配置**
 *  `master`:
    
     *  1.启用`log-bin=master-bin log-bin=master-bin.index`;
     *  2.选择一个唯一的`server-id(0-->2^32)`;
     *  3.创建具有复制权限的用户`REPLICATION SLAVE`\[从主服务器中复制事件的权限\]以及`REPLICATION CLIENT`\[连接主服务器的权限\];
 *  `slave`:
    
     *  1.启用中继日志`relay-log = relay-log relay-log-index`,如果不作为其他`slave`的主时,可以关闭二进制日志;
     *  2.选择唯一一个`server-id(0--->2^32)`;
     *  3.连接至主服务器,并且开始复制数据:
        
         *  1.这里如果主从服务器都是刚刚开始工作,那么数据的复制都从头开始就可以了;
         *  2.如果主服务器已经运行了很久,从服务器刚刚开始工作,可以通过主服务器的完全备份+二进制日志的的位置,然后将完全备份在从服务器上面进行还原,并且从二进制日志的位置开始进行从服务器的同步;
         *  3.`mysql >CHANGE MASTER TO MASTER_HOST=' ',MASTER_PORT=' ',MASTER_LOG_FILE=' ',MASTER_LOG_FILE_POS=' ',MASTER_USER=' ',MASTER_PASSWORD=' ';`
         *  4.启动从服务器的线程:`mysql >START SLAVE;` `mysql > START SLAVE IO_THREAD; mysql > START SLAVE SQL_THREAD;`
 *  `MySQL`的复制线程:  
    ![这里写图片描述][70 4]
 *  `master`会启动`DUMP`线程,来发送改变的二进制日志;
 *  `slave`的两个关键进程:
    
     *  `IO thread`会启动主动去`master`读取二进制日志`Binary log`,如果某些事件是`slave`上面没有的,`master`会通过`DUMP`线程将这些改变发送给`IO thread`,`slave`的`IO thread`线程会接受这些改变,并且保存在中继日志中;
     *  `SQL thread`会启动,读取中继日志,并且在本地进行重放;支持的多线程复制,也就是支持多个`SQL thread`来进行数据的复制;多线程复制对于单个数据库来说,仍然是单个线程的;
 *  对于`IO thread`来说,如果`DUMP`进程宕机或者是`master`宕机,`IO thread`线程就无法工作,但这这个并不影响`SQL thread`的工作,`SQL thread`只需要监控中继日志是否发生改变就可以了,所以说在`salve`进行了某些配置的改变的时候,只需要重新启动`IO thread`这个线程就可以工作了;
 *  **MySQL5.5主从复制架构**

> master: [server60.com][] 172.25.23.100 MySQL 5.5  
> slave:server14.com 172.25.23.14 MySQL 5.5

*  上面的两个版本都是通过编译进行安装的
 *  `master`的配置文件上面启用二进制日志

[root@server60 ~]# vim /etc/my.cnf 
    log-bin=master-bin
    log-bin-index=master-bin.index
    binlog_format=mixed //不建议使用statement
    server-id       = 1 //主从服务器一定不能够一样
    datadir = /mysql/mydata

*  下面这个选项为了以后的一些高级特性,建议添加

innodb_file_per_table = 1

*  然后后启动主服务器

[root@server60 mysql]# /etc/init.d/mysqld start
    Starting MySQL...                                          [  OK  ]

*  添加授权用户

mysql> GRANT REPLICATION SLAVE ON *.* TO 'repluser'@'172.25.23.%' IDENTIFIED BY 'replpass';
    Query OK, 0 rows affected (0.02 sec)
    
    mysql> FLUSH PRIVILEGES;
    Query OK, 0 rows affected (0.01 sec)

*  `slave`上面修改主配置文件

relay-log=relay-log
    relay-log-index=relay-log.index
    server-id       = 2
    innodb_file_per_table = 1
    datadir= /mysql/mydata

*  重新启动服务器

[root@server14 ~]# /etc/init.d/mysqld restart
    Shutting down MySQL.                                       [  OK  ]
    Starting MySQL.                                            [  OK  ]

*  首先查看`master`的状态二进制日志文件以及开始同步的位置  
    ![这里写图片描述][70 5]
 *  修改主服务器从上面的指定的日志文件位置开始进行同步

mysql> CHANGE MASTER TO MASTER_HOST='172.25.23.100', MASTER_USER='repluser', MASTER_PASSWORD='replpass', MASTER_LOG_FILE='master-bin.000001', MASTER_LOG_POS=1568;
    Query OK, 0 rows affected (1.03 sec)

*  查看`slave`的状态

mysql> SHOW SLAVE STATUS\G;
    *************************** 1. row ***************************
                   Slave_IO_State: 
                      Master_Host: 172.25.23.100
                      Master_User: repluser
                      Master_Port: 3306
                    Connect_Retry: 60                    //连接尝试时长
                  Master_Log_File: master-bin.000001     
              Read_Master_Log_Pos: 1568
                   Relay_Log_File: relay-log.000001
                    Relay_Log_Pos: 4
            Relay_Master_Log_File: master-bin.000001
                 Slave_IO_Running: No                //
                Slave_SQL_Running: No
                  Replicate_Do_DB: 
              Replicate_Ignore_DB: 
               Replicate_Do_Table: 
           Replicate_Ignore_Table: 
          Replicate_Wild_Do_Table: 
      Replicate_Wild_Ignore_Table: 
                       Last_Errno: 0
                       Last_Error: 
                     Skip_Counter: 0
              Exec_Master_Log_Pos: 1568
                  Relay_Log_Space: 107
                  Until_Condition: None
                   Until_Log_File: 
                    Until_Log_Pos: 0
               Master_SSL_Allowed: No
               Master_SSL_CA_File: 
               Master_SSL_CA_Path: 
                  Master_SSL_Cert: 
                Master_SSL_Cipher: 
                   Master_SSL_Key: 
            Seconds_Behind_Master: NULL      //slave落后的事件
    Master_SSL_Verify_Server_Cert: No
                    Last_IO_Errno: 0
                    Last_IO_Error: 
                   Last_SQL_Errno: 0
                   Last_SQL_Error: 
      Replicate_Ignore_Server_Ids: 
                 Master_Server_Id: 0
    1 row in set (0.00 sec)

*  接下来启动从服务器

mysql> START  SLAVE;
    Query OK, 0 rows affected (0.03 sec)

*  查看`slave`状态

mysql> SHOW SLAVE STATUS\G;
    *************************** 1. row ***************************
                   Slave_IO_State: Connecting to master
                      Master_Host: 172.25.23.100
                      Master_User: repluser
                      Master_Port: 3306
                    Connect_Retry: 60
                  Master_Log_File: master-bin.000001
              Read_Master_Log_Pos: 1568
                   Relay_Log_File: relay-log.000001
                    Relay_Log_Pos: 4
            Relay_Master_Log_File: master-bin.000001
                 Slave_IO_Running: Connecting
                Slave_SQL_Running: Yes
                  Replicate_Do_DB: 
              Replicate_Ignore_DB: 
               Replicate_Do_Table: 
           Replicate_Ignore_Table: 
          Replicate_Wild_Do_Table: 
      Replicate_Wild_Ignore_Table: 
                       Last_Errno: 0
                       Last_Error: 
                     Skip_Counter: 0
              Exec_Master_Log_Pos: 1568
                  Relay_Log_Space: 107
                  Until_Condition: None
                   Until_Log_File: 
                    Until_Log_Pos: 0
               Master_SSL_Allowed: No
               Master_SSL_CA_File: 
               Master_SSL_CA_Path: 
                  Master_SSL_Cert: 
                Master_SSL_Cipher: 
                   Master_SSL_Key: 
            Seconds_Behind_Master: NULL
    Master_SSL_Verify_Server_Cert: No
                    Last_IO_Errno: 0
                    Last_IO_Error: 
                   Last_SQL_Errno: 0
                   Last_SQL_Error: 
      Replicate_Ignore_Server_Ids: 
                 Master_Server_Id: 0
    1 row in set (0.00 sec)

*  验证主服务器上面创建数据,从服务器上面是否进行数据同步

mysql> CREATE DATABASE newdb;
    Query OK, 1 row affected (0.06 sec)

*  查看`slave`是否存在数据库`newdb`;  
    ![这里写图片描述][70 6]
 *  还需要限制`slave`写入数据,通过以下方式

mysql> FLUSH TABLES WITH READ LOCK;

*  修改服务器参数来限定`slave`为只读;  
    ![这里写图片描述][70 7]
 *  通过配置文件修改全局变量

[root@server14 ~]# vim /etc/my.cnf 
    read-only = 1

*  然后重新启动服务

[root@server14 ~]# /etc/init.d/mysqld restart
    Shutting down MySQL.                                       [  OK  ]
    Starting MySQL.                                            [  OK  ]

*  查看`slave`的复制线程

mysql> SHOW SLAVE STATUS\G;
    *************************** 1. row ***************************
                   Slave_IO_State: Waiting for master to send event
                      Master_Host: 172.25.23.100
                      Master_User: repluser
                      Master_Port: 3306
                    Connect_Retry: 60
                  Master_Log_File: master-bin.000001
              Read_Master_Log_Pos: 1740
                   Relay_Log_File: relay-log.000004
                    Relay_Log_Pos: 254
            Relay_Master_Log_File: master-bin.000001
                 Slave_IO_Running: Yes             //正常运行
                Slave_SQL_Running: Yes
                  Replicate_Do_DB: 
              Replicate_Ignore_DB: 
               Replicate_Do_Table: 
           Replicate_Ignore_Table: 
          Replicate_Wild_Do_Table: 
      Replicate_Wild_Ignore_Table: 
                       Last_Errno: 0
                       Last_Error: 
                     Skip_Counter: 0
              Exec_Master_Log_Pos: 1740
                  Relay_Log_Space: 404
                  Until_Condition: None
                   Until_Log_File: 
                    Until_Log_Pos: 0
               Master_SSL_Allowed: No
               Master_SSL_CA_File: 
               Master_SSL_CA_Path: 
                  Master_SSL_Cert: 
                Master_SSL_Cipher: 
                   Master_SSL_Key: 
            Seconds_Behind_Master: 0
    Master_SSL_Verify_Server_Cert: No
                    Last_IO_Errno: 0
                    Last_IO_Error: 
                   Last_SQL_Errno: 0
                   Last_SQL_Error: 
      Replicate_Ignore_Server_Ids: 
                 Master_Server_Id: 1
    1 row in set (0.00 sec)

*  并且修改的变量已经生效

mysql> SHOW GLOBAL VARIABLES LIKE 'read%';
    +----------------------+---------+
    | Variable_name        | Value   |
    +----------------------+---------+
    | read_buffer_size     | 1048576 |
    | read_only            | ON      |
    | read_rnd_buffer_size | 4194304 |
    +----------------------+---------+

*  关于`master`的信息保存在`file /mysql/mydata/master.info`

[root@server14 ~]# cat /mysql/mydata/master.info
    18
    master-bin.000001
    1827
    172.25.23.100
    repluser                     //用户和密码信息
    replpass
    3306
    60
    0
    
    
    
    
    
    0
    1800.000
    
    0

*  查看这个敏感文件的权限

[root@server14 ~]# ll /mysql/mydata/master.info 
    -rw-rw---- 1 mysql mysql 87 05-15 20:42 /mysql/mydata/master.info

*  查看保存的中继日志文件的信息

[root@server14 ~]# cat /mysql/mydata/relay-log.info 
    ./relay-log.000004
    341
    master-bin.000001
    1827

*  验证上面两种方式,输入的读锁施加之后:
    
     *  第一种方法:无论是`master`还是`salve`都无法进行读写操作;
     *  第二种方法:对于具有`SUPER`权限的用户是不生效的,读写操作都是正常的;
 *  主服务器上面的某些事务在执行没有完成时,`master`出现故障,由于事务日志存在缓冲区,这些信息可能还没有同步到二进制日志中,`slave`是无法得到这些事务信息的,可以通过修改服务器变量,使得事务日志在事务执行完成之后,立即提交,而不是停留在缓冲区中;
 *  查看和日志相关的内容
 *  下面这个选项是应该启用起来的,用于在`master`上面进行设定,用于事务安全;

sync_binlog                              0

*  `slave`在某些情况下是不需要开机立即就去`master`上面同步数据的,例如`master`上面的误删除操作,`slave`的开机启动主要是依赖于`relay-log.info`以及`master.info`,所以可以将这两个文件放到其他位置;
 *  也可以通过开启或者关闭某些线程的方式

mysql> START SLAVE IO_THREAD;
    Query OK, 0 rows affected (0.00 sec)
    
    mysql> START SLAVE SQL_THREAD;
    Query OK, 0 rows affected (0.00 sec)

*  实现`master`和`slave`的半同步操作,这里需要两个插件,在目录`/usr/local/mysql/lib/plugin/`里面

semisync_slave.so  semisync_master.so

*  `ON MASTER`上面进行操作:

*  模块装载成功,但是并没有进行启用
 *  `slave`上面也是需要装载模块的

*  启用主服务器的`rpl_semi_sync_master_enabled`,并且可以定义超时时间

*  接下来启动`slave`上面的

*  现在还是不正常的,现在查看`master`全局状态变量

+--------------------------------------------+-------------+ | Variable_name | Value | +--------------------------------------------+-------------+ | Rpl_semi_sync_master_clients | 0 | | Rpl_semi_sync_master_net_avg_wait_time | 0 | | Rpl_semi_sync_master_net_wait_time | 0 | | Rpl_semi_sync_master_net_waits | 0 | | Rpl_semi_sync_master_no_times | 0 | | Rpl_semi_sync_master_no_tx | 0 | | Rpl_semi_sync_master_status | ON | | Rpl_semi_sync_master_timefunc_failures | 0 | | Rpl_semi_sync_master_tx_avg_wait_time | 0 | | 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 | | Rpl_semi_sync_master_yes_tx | 0 | | Rpl_status | AUTH_MASTER | +--------------------------------------------+-------------+ 15 rows in set (0.00 sec)

*  `Rpl_semi_sync_master_clients`显示的值为`0`;
 *  需要关闭`slave`的线程,并且进行重新连接就可以恢复正常

mysql> STOP SLAVE IO_THREAD;
    Query OK, 0 rows affected (0.01 sec)
    
    mysql> START SLAVE IO_THREAD;
    Query OK, 0 rows affected (0.00 sec)

*  再次查看上面的变量的值,就是正常的了

mysql>  SHOW GLOBAL STATUS LIKE 'Rpl%';
    +--------------------------------------------+-------------+
    | Variable_name                              | Value       |
    +--------------------------------------------+-------------+
    | Rpl_semi_sync_master_clients               | 1           |
    | Rpl_semi_sync_master_net_avg_wait_time     | 0           |
    | Rpl_semi_sync_master_net_wait_time         | 0           |
    | Rpl_semi_sync_master_net_waits             | 0           |
    | Rpl_semi_sync_master_no_times              | 0           |
    | Rpl_semi_sync_master_no_tx                 | 0           |
    | Rpl_semi_sync_master_status                | ON          |
    | Rpl_semi_sync_master_timefunc_failures     | 0           |
    | Rpl_semi_sync_master_tx_avg_wait_time      | 0           |
    | 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           |
    | Rpl_semi_sync_master_yes_tx                | 0           |
    | Rpl_status                                 | AUTH_MASTER |
    +--------------------------------------------+-------------+
    15 rows in set (0.00 sec)

*  在主节点上面执行创建表的操作,时间会明显的变长

mysql> USE newdb;
    Database changed
    mysql> CREATE TABLE tb1(id int);
    Query OK, 0 rows affected (0.76 sec)

*  停止`slave`的`IO_THREAD`线程

mysql> STOP SLAVE IO_THREAD;
    Query OK, 0 rows affected (0.00 sec)

*  在执行表的创建,就会陷入等待,超时时间应该根据实际的需要进行设定  
    ![这里写图片描述][70 8]
 *  查看`master`的服务器状态变量  
    ![这里写图片描述][70 9]
 *  因为`slave`存在一次连接不上,现在自动的降级为异步操作

mysql> CREATE TABLE tb3(id int);
    Query OK, 0 rows affected (0.04 sec)

*  **管理主从服务器的工具percona-tools**
 *  下载并安装

[root@server14 ~]# yum localinstall percona-toolkit-2.2.1-2.noarch.rpm -y --nogpgcheck

*  生成了一堆`pt`开头的命令
    
     *  `pt-slave-delay`:有意使`slave`慢于`master`的,用于在`master`上面误操作时,可以进行挽救;
 *  这些功能需要自己可以去了解

[70]: /images/20220525/0924e7d170004818b75ab2bf2b5f0bd4.png
[70 1]: /images/20220525/2f384cd4b8d147eeac64e426b6067c84.png
[70 2]: /images/20220525/c2bf605cde1b425e8d8c6f777ea8ceec.png
[70 3]: /images/20220525/e401e4dbf67e4df19325a6d71257f5d6.png
[70 4]: /images/20220525/d7866941aa8647d0a130689ae2c4e07f.png
[server60.com]: http://server60.com
[70 5]: /images/20220525/f85a949b26d44a4282dfa825440791c1.png
[70 6]: /images/20220525/f97f878bea2c4ba295b6e83a3afd261a.png
[70 7]: /images/20220525/2d9e737df4bd4985aed2d108b067d5a0.png
[70 8]: /images/20220525/0e1c6664dc8d4e2ea2c0b74e5ca4db20.png
[70 9]: /images/20220525/15dfe8ce20bc4256a69e65448ce2ccc9.png