MySQL之复制(八)

复制

复制和容量规划

备库什么时候开始延迟

一个关于备库比较普遍的问题是如何预测备库会在何时跟不上主库。很难去描述备库使用的复制容量为5%与95%的区别，但是至少能够在接近饱和前预警并估计复制容量。首先应该古纳差复制延迟的尖刺。如果有复制延迟的曲线图，需要注意到图上的一些短暂的延迟骤升，这时候可能负载加大，备库短时间内无法跟上主库。当负载接近耗尽备库的容量时，会发现曲线上的凸起会更高更宽。前面曲线地上升角度不必那，但随后当备库在产生延迟后开始追赶主库时，将会产生一个平缓的斜坡。这些突起的出现和增长是一个警告信息，意味着已经接近容量限制。
为了预测在将来的某个时间点会发生什么，可以人为地制造延迟，然后看多久备库能赶上主库。目的时为了明确地曲线上的斜坡的陡度。如果讲备库停止一个小时，然后开启并在1小时内追赶上，说明正常情况下只消耗了一半的容量。也就是说，如果中午12:00停止备库复制，在1:00开启，并且在2:00追赶上，备库在一小时内完成了两个小时内所有的变更，说明复制可以在双倍速度下运行。
最后，如果使用得时Percona Server或者MariaDB，也可以直接获取复制的利用率。打开服务器变量userstat,然后执行如下语句:

mysql> SELECT * FROM INFORMATION_SCHEMA.USER_STATISTICS WHERE USER='#mysql_system#'\G
*************************** 1. row ***************************
USER:#mysql_system#
TOTAL_CONNECTIONS:1
CONCURRENT_CONNECTIONS:2
CONNECTED_TIME:46188
BUSY_TIME:719
ROWS_FETCHED:0
ROWS_UPDATED:1882292
SELECT_COMMANDS:0
UPDATE_COMMANDS:580431
OTHER_COMMANDS:338857
COMMIT_TRANSACTIONS:1016571
ROLLBACK_TRANSACTIONS:0

可以讲BUSY_TIME和CONNECTED_TIME的一半(因为备库有两个复制线程)做比较,来观察备库线程实际执行命令所花费的事件(如果复制线程总是在运行，你可以使用服务器的uptime来代替CONNECTED_TIME的一半)。在该例子中，备库大约使用了其3%的能力，这并不意味着它不会遇到偶然的延迟尖刺——如果主库运行了一个超过10分钟才完成的变更，可能延迟的事件和变更执行的事件是相同的——但这很好地暗示了备库能够很快从一个延迟尖刺中恢复

规划冗余容量

在构建一个大型应用时，有意让服务器不被充分利用，，这应该是一种聪明并且划算的方式，尤其在使用复制的时候。有多余容量的服务器可以更好地处理负载尖峰，也有更多能力处理慢速查询和维护工作(如OPTIMIZE TABLE ),并且能够更好地跟上复制，试图同时向主-主拓扑结构的两个节点写入来减少复制问题通常是不划算的。分配给每台机器的读负载应该低于50%，否则，如果某台机器失效，就没有足够的容量了，如果两台服务器都能独立处理负载，就用不着担心复制的问题了。。构建冗余容量也是实现高可用性的最佳方式之一，当然还有别的方式，例如，当错误发生时让应用在降级模式下运行

复制管理和维护

配置复制一般来说不会是需要经常做的工作，除非有很多服务器。但是一旦配置了复制，监控和管理复制拓扑应该称为一项日常工作，不管有多少服务器。这些工作应该尽量自动化，但不一定需要自己写工具来实现.,可以借助第三方的工具或插件。

监控复制

复制增加了MySQL监控的复杂性。尽管复制发生在主库和备库上，但大多数工作是在备库上完成的，这也正式最常出问题的地方。是否所有的备库都在工作？最慢的备库延迟是多大？MySQL本身提供了大量可以回答上述问题的信息，弹药实现自动化监控过程以及使复制更健壮还是需要用户做更多的工作。
在主库上，可以使用SHOW MASTER STATUS命令来查看当前主库的二进制日志位置和配置。还可以查看主库当前有哪些二进制日志在磁盘上的:

mysql>SHOW MASTER LOGS;

该命令用于给PURGE MASTER LOGS命令决定使用哪个参数。另外还可以通过SHOW BINLOG EVENTS来查看复制事件。例如，在运行前一个命令后，我们在另一个不曾使用过的服务器上创建一个表，因为知道这是唯一改变数据的语句，而且也知道语句在二进制日志中的偏移量是319，所以我们能看到如下内容:

测量备库延迟

一个比较普遍的问题是如何监控备库落后主库的延迟有多大。虽然SHOW SLAVE STATUS输出的Seconds_behind_master列理论上显示了备库的延时，但由于各种各样的原因，并不总是准确的:

• 1.备库Seconds_behind_master值是通过讲服务器当前的时间戳与二进制日志中的事件的时间戳相对比得到的，所以只有在执行事件时才能报告延迟。
• 2.如果备库复制线程没有运行，就会报延迟为NULL
• 3.一些错误(例如主备的max_allowed_packet不匹配，或者网络不稳定)可能中断复制并且/或者停止复制线程，但Seconds_behind_master将显示为0而不是显示错误
• 4.即使备库线程正在运行，备库有时候可能无法计算延时，如果法政这种情况，备库会报0或者NULL
• 5.一个大事务可能会导致延迟波动，例如，有一个事务更新数据长达一个小时，最后提交。这条更新将比它实际发生时间要晚一个小时才记录到二进制日志中。当备库执行这条语句时，会临时地报告备库延迟为一个小时，然后又很快变成0
• 6.如果分发主库落后了，并且其本身也有已经追赶上它的备库，备库的延迟将显示为0，而事实上和源主库之间是有延迟的。

解决这些问题的办法是忽略Seconds_behind_master的值，并使用一些可以直接观察和衡量的方式来监控备库延迟。最好的解决办法是使用heartbeat record，这是一个在主库上会每秒更新一次的时间戳。为了计算延时，可以直接用备库当前的时间戳减去心跳记录的值。这个方法能够解决刚刚我们提到的所有问题，另外一个额外的好处是我们还可以通过时间戳知道备库当前的复制状况。包含在Percona Toolkit里的pt-heartbeat脚本是"复制心跳"最流行的一种实现。心跳还有其他好处，记录在二进制日志中的心跳记录拥有多种用途，例如在一些很难解决的场景下可以用于灾难恢复。
刚刚所描述的几种延迟指标都不能表明备库需要多长时间才能赶上主库，这依赖于许多因素，例如备库的写入能力以及主库持续写入的次数。