MySQL 8复制性能的增强
- 2018.3.3
- 版权声明：本文为博主chszs的原创文章，未经博主允许不得转载。
MySQL从5.7版发布后没多久，其8.0版本的开发就提上了日程。MySQL在编号方面跳跃了几个版本，6.0被直接丢弃，7.0被保留用于MySQL的集群版本，因为Oracle官方认为，MySQL 5.6版就相当于6.0版，5.7版就相当于7.0版，因此作为5.7版的下一个版本，直接命名为8.0版也就可以理解了。8.0版这个新版本有许多改变（和bug修复），其中最令人兴奋的是复制性能的增强。本文将概述复制性能增强的特性，包括新增的复制时间戳、性能模式表报告的其他信息，以及通过更新复制线程之间的关系以降低复制延迟的效率，从而降低复制延迟。
新的复制时间戳
管理复制过程中最常见的任务是确保实际上正在发生的复制的顺利进行，并且从设备与主设备之间没有错误。使用的主要语句是“SHOW SLAVE STATUS”，它提供了有关从线程的基本参数的状态信息。因此，必须在每个从设备上执行它。以下是一个输出示例：
mysql> SHOW SLAVE STATUS\G
*************************** 1. row ***************************
Slave_IO_State: Waiting for master to send event
Master_Host: localhost
Master_User: root
Master_Port: 13000
Connect_Retry: 60
Master_Log_File: master-bin.000002
Read_Master_Log_Pos: 1307
Relay_Log_File: slave-relay-bin.000003
Relay_Log_Pos: 1508
Relay_Master_Log_File: master-bin.000002
Slave_IO_Running: Yes
Slave_SQL_Running: Yes
/ * / * / * /
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:
ETC...
其中一个输出度量是Seconds_Behind_Master。虽然这完全适用于简单的主从设置，但此度量标准不适合更复杂的复制场景。Seconds_Behind_Master度量有四个主要缺点：
- 它只报告从设备和最高层主设备之间的延迟。例如，在链式复制设置中，Seconds_Behind_Master只报告相对于原始主设备的延迟，而不提供任何关于从设备与其最近的中间层注设备之间的延迟的信息。
- 它与原始主设备的时区相关。因此，跨时区的服务器的复制会导致测量的延迟被两台服务器之间的时区差异所抵消。
- 根据语句的执行开始时间，以每个事件为基础测量延迟。从事务处理实际发生在主事务处理的时间起，更具有洞察力的措施将是每笔事务处理。
- 用于度量复制延迟的时间戳只能提供精确到最近的秒数。
MySQL 8引入了两个新的时间戳，这些时间戳Seconds_Behind_Master在规避上述问题时补充了度量标准。这些时间戳与每个事务的全局事务标识符（GTID）相关联（与每个事件相对），写入二进制日志。GTID是创建的唯一标识符，并与源（主）服务器上提交的每个事务相关联。此标识符不仅是其源自的服务器，而且是给定复制设置中的所有服务器的唯一标识符。与事务处理相关联，所有事务处理和所有GTID之间存在1对1的映射关系。
这两个新的时间戳是：
- 原始提交时间戳（OCT，Original Commit Timestamp）：将事务写入原始主服务器的二进制日志时的微秒数（起始时间为1970-01-01T00:00:00Z）
- 即时提交时间戳（ICT，Immediate Commit Timestamp）：事务处理写入即时主机的二进制日志花销的微秒数
mysqlbinlog以两种格式显示新的时间戳：
- 微秒数
- 在用户时区的TIMESTAMP格式（为了更好的可读性）
从设备的二进制日志中的这段代码显示了两个时间戳：
#170404 10:48:05 server id 1 end_log_pos 233 CRC32 0x016ce647 GTID
last_committed=0 sequence_number=1
original_committed_timestamp=1491299285661130
immediate_commit_timestamp=1491299285843771
# original_commit_timestamp=1491299285661130 (2018-01-04 10:48:05.661130 WEST)
# immediate_commit_timestamp=1491299285843771 (2018-01-04 10:48:05.843771 WEST)
/*!80001 SET @@session.original_commit_timestamp=1491299285661130*//*!*/;
SET @@SESSION.GTID_NEXT= 'aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa:1'/*!*/;
# at 288
性能模式表报告的新信息
MySQL 8.0对性能模式进行了一些更改，从而获得更好的性能信息和更多的指标信息：
- 可以检测服务器错误
- 现在支持索引
- 可以向现有的性能模式复制状态表添加新的字段
下面详细地探讨这些内容。
检测服务器错误
MySQL 8引入了五个新的汇总表来帮助处理服务器错误，包括：
- events_errors_summary_by_account_by_error
- events_errors_summary_by_host_by_error
- events_errors_summary_by_thread_by_error
- events_errors_summary_by_user_by_error
- events_errors_summary_global_by_error
在所有上述表中，错误统计数据都会被错误汇总。此外，除了events_errors_summary_global_by_error之外，每个表都存储与特定用户、主机、帐户或线程相关的错误；events_errors_summary_global_by_error包含整个服务器的错误。
表结构
每个表都包含以下字段：
+-------------------+---------------------+------+-----+---------------------+
| Field | Type | Null | Key | Default |
+-------------------+---------------------+------+-----+---------------------+
| ERROR_NUMBER | int(11) | YES | | NULL |
| ERROR_NAME | varchar(64) | YES | | NULL |
| SQL_STATE | varchar(5) | YES | | NULL |
| SUM_ERROR_RAISED | bigint(20) unsigned | NO | | NULL |
| SUM_ERROR_HANDLED | bigint(20) unsigned | NO | | NULL |
| FIRST_SEEN | timestamp | YES | | 0000-00-00 00:00:00 |
| LAST_SEEN | timestamp | YES | | 0000-00-00 00:00:00 |
+-------------------+---------------------+------+-----+---------------------+
注意：
- FIRST_SEEN/LAST_SEEN列字段表示第一次和最后一次看到的特定错误。
- SUM_ERROR_RAISED列字段列出了引发特定错误的次数。