MySQL第八讲 MySQL集群扩容与半同步复制

集群扩容

      我们现在已经搭建成功了一主一从的MySQL集群架构，那要扩展到一主多从的集

群架构，其实就比较简单了，只需要增加一个binlog复制就行了。 但是如果我们的集群是已经运行过一段时间，这时候如果要扩展新的从节点就有 一个问题，之前的数据没办法从binlog来恢复了。这时候在扩展新的slave节点时， 就需要增加一个数据复制的操作。

     MySQL的数据备份恢复操作相对比较简单，可以通过SQL语句直接来完成。具体

操作可以使用mysql的bin目录下的mysqldump工具。

mysqldump -u root -p --all-databases > backup.sql

# 输入密码

        通过这个指令，就可以将整个数据库的所有数据导出成backup.sql，然后把这个 backup.sql分发到新的MySQL服务器上，并执行下面的指令将数据全部导入到新的 MySQL服务中。

mysql -u root -p < backup.sql

# 输入密码

        这样新的MySQL服务就已经有了所有的历史数据，然后就可以再按照上面的步 骤，配置Slave从服务的数据同步了。

半同步复制

     Mysql的主从集群和互主集群都存在一个隐患，就是有可能会丢数据。这是为什么呢？这要从MySQL主从数据复制分析起。

     MySQL主从集群默认采用的是一种异步复制的机制。主服务在执行用户提交的事 务后，写入binlog日志，然后就给客户端返回一个成功的响应了。而binlog会由一 个dump线程异步发送给Slave从服务。

       由于这个发送binlog的过程是异步的。主服务在向客户端反馈执行结果时，是不 知道binlog是否同步成功了的。这时候如果主服务宕机了，而从服务还没有备份到 新执行的binlog，那就有可能会丢数据。那怎么解决这个问题呢，这就要靠MySQL的半同步复制机制来保证数据安全。

      半同步复制机制是一种介于异步复制和全同步复制之前的机制。主库在执行完客 户端提交的事务后，并不是立即返回客户端响应，而是等待至少一个从库接收并写 到relay log中，才会返回给客户端。MySQL在等待确认时，默认会等10秒，如果超 过10秒没有收到ack，就会降级成为异步复制。

          这种半同步复制相比异步复制，能够有效的提高数据的安全性。但是这种安全性 也不是绝对的，他只保证事务提交后的binlog至少传输到了一个从库，并且并不保 证从库应用这个事务的binlog是成功的。另一方面，半同步复制机制也会造成一定 程度的延迟，这个延迟时间最少是一个TCP/IP请求往返的时间。整个服务的性能是会有所下降的。而当从服务出现问题时，主服务需要等待的时间就会更长，要等到 从服务的服务恢复或者请求超时才能给用户响应。

搭建半同步复制集群

         半同步复制需要基于特定的扩展模块来实现。而mysql从5.5版本开始，往上的版 本都默认自带了这个模块。这个模块包含在mysql安装目录下的lib/plugin目录下的 semisync_master.so和semisync_slave.so两个文件中。需要在主服务上安装 semisync_master模块，在从服务上安装semisync_slave模块。

 首先我们登陆主服务，安装semisync_master模块：

mysql> show master status;
+-------------------+----------+--------------+--------------------------------------------+-------------------+
| File              | Position | Binlog_Do_DB | Binlog_Ignore_DB                           | Executed_Gtid_Set |
+-------------------+----------+--------------+--------------------------------------------+-------------------+
| master-bin.000008 |      157 | testdemo     | information_schema,performation_schema,sys |                   |
+-------------------+----------+--------------+--------------------------------------------+-------------------+
1 row in set (0.00 sec)

mysql> install plugin rpl_semi_sync_master soname 'semisync_master.so';
Query OK, 0 rows affected, 1 warning (0.00 sec)

mysql> show global variables like 'rpl_semi%';
+-------------------------------------------+------------+
| Variable_name                             | Value      |
+-------------------------------------------+------------+
| rpl_semi_sync_master_enabled              | OFF        |
| rpl_semi_sync_master_timeout              | 10000      |
| rpl_semi_sync_master_trace_level          | 32         |
| rpl_semi_sync_master_wait_for_slave_count | 1          |
| rpl_semi_sync_master_wait_no_slave        | ON         |
| rpl_semi_sync_master_wait_point           | AFTER_SYNC |
+-------------------------------------------+------------+
6 rows in set (0.00 sec)

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

mysql> show global variables like 'rpl_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_for_slave_count | 1          |
| rpl_semi_sync_master_wait_no_slave        | ON         |
| rpl_semi_sync_master_wait_point           | AFTER_SYNC |
+-------------------------------------------+------------+
6 rows in set (0.00 sec)

install plugin rpl_semi_sync_master soname 'semisync_master.so'; 是通过扩展库来安装半同步复制模块，需要指定 扩展库的文件名。

show global variables like 'rpl_semi%';  查看系统全局参数

rpl_semi_sync_master_timeout就是半同步 复制时等待应答的最长等待时间，默认是10秒，可以根据情况自行调整

set global rpl_semi_sync_master_enabled=ON;   是打开半同步复制的开关。

rpl_semi_sync_master_wait_point其实表示一种半同步复制的方式。

半同步复制有两种方式，一种是我们现在看到的这种默认的 AFTER_SYNC方式。这种方式下，主库把日志写入binlog，并且复制给 从库，然后开始等待从库的响应。从库返回成功后，主库再提交事务， 接着给客户端返回一个成功响应。

而另一种方式是叫做AFTER_COMMIT方式。他不是默认的。这种方式， 在主库写入binlog后，等待binlog复制到从库，主库就提交自己的本地 事务，再等待从库返回给自己一个成功响应，然后主库再给客户端返回响应。

然后我们登陆从服务，安装smeisync_slave模块

mysql> install plugin rpl_semi_sync_slave soname 'semisync_slave.so';
Query OK, 0 rows affected, 1 warning (0.00 sec)

mysql> show global variables like 'rpl_semi%';
+---------------------------------+-------+
| Variable_name                   | Value |
+---------------------------------+-------+
| rpl_semi_sync_slave_enabled     | OFF   |
| rpl_semi_sync_slave_trace_level | 32    |
+---------------------------------+-------+
2 rows in set (0.00 sec)

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

mysql> show global variables like 'rpl_semi%';
+---------------------------------+-------+
| Variable_name                   | Value |
+---------------------------------+-------+
| rpl_semi_sync_slave_enabled     | ON    |
| rpl_semi_sync_slave_trace_level | 32    |
+---------------------------------+-------+
2 rows in set (0.00 sec)

mysql>  stop slave;
Query OK, 0 rows affected, 1 warning (0.00 sec)

mysql> start slave;
Query OK, 0 rows affected, 1 warning (0.02 sec)

slave端的安装过程基本差不多，不过要注意下安装完slave端的半同步插 件后，需要重启下slave服务。

主从架构的数据延迟问题

      在我们搭建的这个主从集群中，有一个比较隐藏的问题，就是这样的主从复制之 间会有延迟。这在做了读写分离后，会更容易体现出来。即数据往主服务写，而读 数据在从服务读。这时候这个主从复制延迟就有可能造成刚插入了数据但是查不 到。当然，这在我们目前的这个集群中是很难出现的，但是在大型集群中会很容易出现。

    出现这个问题的根本在于：面向业务的主服务数据都是多线程并发写入的，而从 服务是单个线程慢慢拉取binlog，这中间就会有个效率差。所以解决这个问题的关键是要让从服务也用多线程并行复制binlog数据。 MySQL自5.7版本后就已经支持并行复制了。

    可以在从服务上设 slave_parallel_workers为一个大于0的数，然后把slave_parallel_type参数设置 LOGICAL_CLOCK，这就可以了。