MySQL主从复制集群

最新推荐文章于 2024-07-15 22:05:24 发布

bug--maker

最新推荐文章于 2024-07-15 22:05:24 发布

阅读量2.2k

点赞数 1

分类专栏： Mysql 文章标签： Mysql5.5主从架构 Mysql5.5-percona复制

本文链接：https://blog.csdn.net/qq_36294875/article/details/80309969

版权

Mysql 专栏收录该内容

10 篇文章 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的负担;
修改后的主从复制架构
对于第二个节点:
- 1.首先需要启动多个线程来将二进制日志同步给其余的master节点;
- 2.其次,第二个节点需要多个线程来负责中继日志的处理,这个节点就不应该处理读请求,这个节点既不处理读请求,也不处理写请求,但是需要通过写入数据的操作来产生二进制日志,这里就需要使用特殊的存储引擎BLACK_HOLL存储引擎,通过这个机制可以减轻节点IO处理压力;
在MySQL服务器架构中,不适用MySQL 代理,如何实现主写从读,这个功能可以交给PHP连接MySQL的应用程序来解决,通过制定主服务器和从服务器来实现读写分离,但是这种方法也存在缺点,会破坏负载均衡,因为制定的算法都是各自进行调度的;
如果不想通过上述两种办法来解决,那么就可以通过MySQL的双主模型来解决,但是不建议使用这种方式,因为性能低下;
双主模型的工作原理
上述模型可能出现的问题:
* 由于数据中继日志写入,会更新二进制日志,然后二进制日志会在另一个服务器上面执行,生成新的二进制日志,这样会导致无限循环;
* 对于上面的问题需要引入服务器ID用于标示语句的执行情况,对于中继日志执行的写入操作,是必须写入自己的二进制日志文件里面的,因为一旦这个master作为了slave的master,二进制就是不完善的 ,所以server ID为对方ID的是必须写入二进制日志的;
二进制日志中的格式会记录这个问题
双主模型是可以分担的是读负载,但是不能够分担写负载;
双主模型可能出现下面的问题:
会因为更新特殊的数据导致数据不一致无法合并的问题;
主键使用的增长导致的主键冲突的问题;
当数据库的内容十分庞大时,查询,写入速度十分缓慢时,可以采用拆库的策略,将各个库独立出来,用于减轻服务器的压力;
垂直拆分:将一个库拆分为多个库,数据库存在数据热区的,有时候是某张表的频繁查询减低了查询速度;
水平拆分:可以将表进行拆分;
在执行水平拆分以及垂直拆分之后,当查询的操作涉及多个表,并且需要将这些表的数据整合返回时,就需要借助于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的复制线程:
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的状态二进制日志文件以及开始同步的位置
修改主服务器从上面的指定的日志文件位置开始进行同步

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;
还需要限制slave写入数据,通过以下方式

mysql> FLUSH TABLES WITH READ LOCK;

修改服务器参数来限定slave为只读;
通过配置文件修改全局变量

[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上面进行操作:

mysql> INSTALL PLUGIN rpl_semi_sync_master SONAME 'semisync_master.so';
Query OK, 0 rows affected (0.20 sec)

mysql> SHOW GLOBAL VARIABLES LIKE '%rpl%';
+------------------------------------+-------+
| Variable_name                      | Value |
+------------------------------------+-------+
| rpl_recovery_rank                  | 0     |
| rpl_semi_sync_master_enabled       | OFF   |
| rpl_semi_sync_master_timeout       | 10000 |
| rpl_semi_sync_master_trace_level   | 32    |
| rpl_semi_sync_master_wait_no_slave | ON    |
+------------------------------------+-------+
5 rows in set (0.00 sec)

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

mysql> INSTALL PLUGIN rpl_semi_sync_slave SONAME 'semisync_slave.so';
Query OK, 0 rows affected (0.01 sec)

mysql> SHOW GLOBAL VARIABLES LIKE '%rpl%';
+---------------------------------+-------+
| Variable_name                   | Value |
+---------------------------------+-------+
| rpl_recovery_rank               | 0     |
| rpl_semi_sync_slave_enabled     | OFF   |
| rpl_semi_sync_slave_trace_level | 32    |
+---------------------------------+-------+
3 rows in set (0.00 sec)

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

mysql> SET GLOBAL rpl_semi_sync_master_enabled=1;
Query OK, 0 rows affected (0.00 sec)

mysql> SHOW GLOBAL VARIABLES LIKE '%rpl%';
+------------------------------------+-------+
| Variable_name                      | Value |
+------------------------------------+-------+
| rpl_recovery_rank                  | 0     |
| 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    |
+------------------------------------+-------+
5 rows in set (0.00 sec)

接下来启动slave上面的

mysql> set global rpl_semi_sync_slave_enabled=1;
Query OK, 0 rows affected (0.00 sec)

mysql> SHOW GLOBAL VARIABLES LIKE '%rpl%';
+---------------------------------+-------+
| Variable_name                   | Value |
+---------------------------------+-------+
| rpl_recovery_rank               | 0     |
| rpl_semi_sync_slave_enabled     | ON    |
| rpl_semi_sync_slave_trace_level | 32    |
+---------------------------------+-------+
3 rows in set (0.00 sec)

现在还是不正常的,现在查看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)

在执行表的创建,就会陷入等待,超时时间应该根据实际的需要进行设定
查看master的服务器状态变量
因为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上面误操作时,可以进行挽救;
这些功能需要自己可以去了解

bug--maker

关注

1
点赞
踩
0

收藏

觉得还不错? 一键收藏
0
评论
MySQL主从复制集群

二进制日志:事务日志:错误日志:
复制链接

扫一扫

专栏目录