mysql5.5/5.6主从复制改进

转载自：http://bbs.baofengcloud.com/home.php?mod=space&uid=30&do=blog&quickforward=1&id=8

1.mysql5.5改进

     MySQL 数据库系统的复制（Replication）功能是使用广泛且最受欢迎的功能，因为它具有可扩展性，并为数据冗余和实用性提供了便捷、有力的解决方案。在 MySQL5.5 中，我们根据用户的要求，对复制功能进行了增强，从而提供更好的实用性：

• 确保主服务器和从服务器之间数据的一致性
• 如果复制不能正常工作，立即检测
• 允许崩溃的从服务器依据主服务器的中继日志（Relay Log）自动恢复
• 允许用户为特定的服务器过滤各种事件
• 正确转换主服务器和从服务器之间的数据类型

MySQL5.5 复制功能包括以下几个增强措施，可在关键操作给予用户支持：

1.1.半同步复制（Semi-synchronous Replication）

     默认情况下，MySQL5.5 的复制功能是异步的，这意味着当谈到数据一致性时，主服务器及其从服务器是独立的。异步复制可以提供最佳的性能，因为主服务器在将更新的数据写入它的二进制日志（Binlog）文件中后，无需等待验证更新数据是否已经复制到至少一台拓扑从服务器中，就可以自由处理其它进入的事务处理请求。虽然快，但这也同时带来了很高的风险，如果在主服务器或从服务器端发生故障，会造成主服务器/从服务器数据的不一致，甚至在恢复时造成数据丢失。

     MySQL5.5 引入了一种半同步复制功能，该功能可以确保主服务器和访问链中至少一台从服务器之间的数据一致性和冗余。在这种配置结构中，一台主服务器和其许多从服务器都进行了配置，这样在复制拓扑中，至少有一台从服务器在父主服务器进行事务处理前，必须确认更新已经收到并写入了其中继日志（Relay Log）。在超时的情况下也可以临时转入异步复制，保障业务的正常使用，直到一台salve追赶上之后，继续切换到半同步模式。

     半同步复制模式必须在主服务器和从服务器端同时启用，否则主服务器默认使用异步复制模式。MySQL5.5 使用一种全新的插件构架实现了半同步复制模式。为此，请使用下面的命令和变量设置启动MySQL5.5 主服务器和从服务器。静态设置信息也可添加到―my.*‖配置文件中：

启动主服务器的半同步复制功能：

INSTALL PLUGIN 'rpl_semi_sync_master' SONAME 'semisync_master.so';

SET rpl_semi_sync_master_enabled=1;

SET rpl_semi_sync_master_timeout=1000; (1 秒, 默认为 10 秒)

启动从服务器或多个从服务器的半同步复制功能：

INSTALL PLUGIN 'rpl_semi_sync_slave' SONAME 'semisync_slave.so';

SET rpl_semi_sync_slave_enabled=1;

START SLAVE;

     一旦启动半同步复制模式，将会显示出新系统及其状态变量，这些变量可用于检查配置和运行状态。每个值使用 SHOW VARIABLES 和 SHOW STATUS 显示，包括：

在主服务器中：

• Rpl_semi_sync_master_status –用于指示主服务器使用的是异步复制模式，还是半同步复制模式
• Rpl_semi_sync_master_clients –用于显示有多少个从服务器配置成了半同步复制模式
• Rpl_semi_sync_master_yes_tx – 显示从服务器确认的成功提交数量
• Rpl_semi_sync_master_no_tx – 显示从服务器确认的不成功提交数量

在从服务器中：

• Rpl_semi_sync_slave_status –用于指示从服务器是否启动半同步复制模式

1.2.复制 Heartbeat

     MySQL5.5 提供了一种全新的复制 Heartbeat 选项，当复制功能停止工作时，该选项能够帮助用户立刻察觉问题。Heartbeat 是一种定期从主服务器节点发送到从服务器节点的消息。可将从服务器配置成自动检查连接和消息的状态；如果从服务器没有接收到该消息，那么从服务器应该知道，与主服务器之间的节点连接出现了故障。

     复制 Heartbeat 是一种可选配置，使用下列命令在 MySQL5.5 从服务器上启用：

STOP SLAVE;

CHANGE MASTER TO master_heartbeat_period= milliseconds;

START SLAVE;

     监控下面的状态变量，可以很容易检测到主服务器是否空闲，并瞬间获得从服务器的细粒度（Finer-Grained）估计，以用于恢复：

SHOW STATUS like 'slave_heartbeat period'

SHOW STATUS like 'slave_received_heartbeats'

1.3.中继日志自动恢复（Automatic Relay Log Recovery）

     在MySQL5.5版本之前，MySQL Slave实例在异常终止服务之后，可能导致复制中断，并且relay binlog可能损坏，在MySQL再次启动之后并不能正常恢复复制。在MySQL5.5中这一问题得到了解决，MySQL可以自行丢弃顺坏的而未处理的数据，重新从master上获取源数据，进而回复复制。在启动时，MySQL5.5 允许用户随意配置从服务器，自动丢弃自己未处理的中继日志（Relay Log），然后从源主机服务器恢复挂起的事务处理，从而确保了主服务器/从服务器的数据一致性。这种方法可以确保当从服务器崩溃后，潜在可能崩溃的备份日志不被处理。出于兼容性考虑，默认情况下该功能是关闭的，将 relay_log_recovery 的值设置为 1 时，可在从服务器上开启该功能。

1.4.根据服务器过滤项复制（Replication Per Server Filtering）

     循环或多主服务器复制，提供了一种可用度非常高的部署方案，该方案可在拓扑环中的任何服务器发生故障或移走的情况下，确保数据的冗余。在这种配置方案中，需要对拓扑环中所有主服务器进行配置，使每个主服务器同时也是一个从服务器。写入任何主服务器的更新信息会在拓扑环中的主机中依次进行复制，直到重新回到源服务器（这个服务器是自己事件消息的终止器）。当某个节点发生故障时，将受影响的服务器从拓扑环中移除，然后简单地将拓扑环中的另外一台服务器指定为它的从服务器，并继续处理。在这里我们说明一下：

     在之前的几个版本中，当某个服务器由于故障、维护等原因从拓扑环中移除时，用户需要手动确保在新的呼叫链中终止所有的更新信息。MySQL5.5 提供了一组新的省时的命令，用户使用这组命令很容易就可以过滤出与已移除服务器相关的事件。在上述例子中，当服务器A 从拓扑环中移除后，用户现在可以在呼叫链中的下一台服务器中输入下面的命令，即可过滤出任何与服务器A 相关的事件：

     Server B> CHANGE MASTER TO MASTER_HOST=D IGNORE_SERVER_IDS=(A)

1.5.从服务器复制支持的数据类型转换（Replication Slave Side Data Type Conversions）

     在MySQL5.1 中，主服务器和从服务器间精确的数据类型转换仅被基于声明的复制支持。在这种配置中，只要底层数据有较好的兼容性（例如，从INT 型转换到TINYIN 类型），主服务器和从服务器中表类型可以不同。现在MySQL5.5 在主服务器和从服务器之间提供了一种精确的数据类型转换机制，受基于声明的操作和基于行的操作支持。支持整数、小数、字符串、二进制、BIT、ENUM（枚举类型）和SET（集合）域之间的转换。

     在MySQL5.5 中，新的SET 类型变量可以启动变换操作，但需要重新启动从服务器后才可以生效。设置以及可以启动的变换如下：

SET SLAVE_TYPE_CONVERSIONS=‖ALL_LOSSY’ –向较小域类型的转换（例如，INT 转换为TINY）

SET SLAVE_TYPE_CONVERSION=‖ALL_NON_LOSSY‖ –向较大域类型的转换（例如TINY 转换为INT）

2.mysql5.6改进

• slave使用表来保存复制信息
• 复制事件checksum
• 多线程slave
• 延时复制
• 优化了基于行的复制
• 全局事务标识IDS

2.1.slave使用表来保存复制信息

• 系统表:

– mysql.slave_master_info (master.info)

– mysql.slave_relay_log_info (relay-log.info)

启动的时候设置或添加参数到my.cnf

--master-info-repository=TABLE

--relay-log-info-repository=TABLE

启动后设置

SET GLOBAL master_info_repository = 'TABLE';

SET GLOBAL relay_log_info_repository = 'TABLE';

start slave;

2.2.复制事件checksun

binlog-checksum= NONE or CRC32 
     每个 session都会产生checksum值，并且写入到binlog 
     mysql> SET GLOBAL binlog_checksum = 1;
master-verify-checksum= 0 or 1
     Master 当从binlog dump事件的时候会校验checksum值
     mysql> SET GLOBAL master_verify_checksum = 1;
slave-sql-verify-checksum= 0 or 1 
     SQL线程当从relay log读取事件应用到slave之前会校验checksum值       

     mysql> SET GLOBAL slave_sql_verify_checksum=1;

binlog-checksum对应图中1
master-verify-checksum对应图中2
slave-sql-verify-checksum对应图中5

2.3.多线程slave

性能上的改进：
• 提高了slave 性能
• slave端的sql应用在不同数据库间变成并行:减少了slave的滞后,增加了slave的吞吐量
• 变成数据库（schema）级别的复制，每个数据库的更改将会被应用，注意这里每个库的应用还是串行的，并且提交变得相互独立
• 在重启恢复的时候是自动完成的（串行）
• Slave所有的事务日志都已经写入到了relay log保证了数据不丢失。
最糟糕的情况是所有的操作都是对同一个库进行操作。

设置slave_parallel_workers参数，开启基于库的多线程复制。默认是0，不开启，最大并发数为1024个线程。

mysql> SET GLOBAL slave_parallel_workers=2;

mysql> show global variables;
• 0 – 禁用
• 最大 1024

影响单个slave 的worker线程的队列的参数为slave_pending_jobs_size_max

2.4.延时复制

     通常我们做mysql主从复制关心的是如何避免主从之间的延时，但是有一种需求却是希望slave延时一段时间后再从master复制数据，最大支持 68 年后再复制。

     设置方法为在change master to中增加MASTER_DELAY = N;从master接受的event事件等到过了n秒后才在slave上面执行。

2.5.优化了基于行的复制

     新选项：binlog-row-image=minimal

2.6.全局事务标识IDS

     Global Transaction Identifier(全局事务表示符，实际上是以一个事件的形式存在mysql 中)在每个事务提交时会立刻记录到binlog 中,在binlog中每次的提交都会有GTD标示符。

     GTD结构如下：GTID =

• SID目前，它是一个128位的数字，用于标识提交的事务/（组提交事务）事件。 SID通常是服务器的UUID，但可能不同，如果事务是由innodb以外的存储引擎可能不同。例如，对于NDB的，它将表示整个集群。
• GNO是一个64位序列号：1代表第一次改变记录的SID，2代表第二变化，等等。没有变化，可以表示为：GNO0。

要求mysql 5.6 在master 和 slave都要做

# 修改配置文件 my.cnf 在msater和slave 上

# (master and slaves)

[mysqld]

log-bin

log-slave-updates

gtid-mode=ON

disable-gtid-unsafe-statements=ON

# 重启 servers

mysql> STOP SLAVE;

mysql> CHANGE MASTER TO

> MASTER_HOST = master-host,

> MASTER_PORT = master-port,

> MASTER_USER = repl-user,

> MASTER_PASSWORD = repl-password,

> MASTER_AUTO_POSITION = 1;

mysql> START SLAVE;

     MASTER_AUTO_POSITION=1 将会代替以前手动使用的MASTER_LOG_FILE 和MASTER_LOG_POS,告诉服务器使用GTD(GTD协议会使得中从实现握手操作),这个时候，当slave启动的时候，master和slave 将会自动相互通信，然后slave从正确的时间点向后开始复制，这个切换过程只需要slave上操作MASTER_AUTO_POSITION=1，以后的整个复制过程将是自动的。注意这里从的binlog里记录的 GTD是主的GTD。

     注：如果你使用了GTID，那么就不能再使用传统binlog和POS方式