对复制实施主键约束
作者：Pedro Gomes 译：徐轶韬
在本文中，我们介绍一个配置选项，该选项控制复制通道是否允许创建没有主键的表。这延续了我们最近在复制安全性方面的工作，在该工作中，我们允许用户强制执行权限检查和/或强制执行基于行的事件。
在8.0.20上，我们为CHANGE MASTER TO语句引入了一个新选项：REQUIRE_TABLE_PRIMARY_KEY_CHECK。复制通道在执行创建或更改表定义及其主键时可以选择自己的策略。
在表定义上强制主键很重要。例如，在使用基于行的日志模式下进行复制时，表的主键对从数据库的性能起着重要作用。服务器中使用变量sql_require_primary_key强制执行此策略。在复制的上下文中，该变量的值将与所有更改表结构（也称为DDL）的查询一起发送，因此从数据库将遵循主数据库上的任何限制。
如果从数据库的操作员无法控制或信任主服务器，仅仅遵循在那里定义的限制是不够的。因此，现在可以用REQUIRE_TABLE_PRIMARY_KEY_CHECK的值来影响此行为。
可以在复制通道上将此参数设置为：
- ON：复制通道在复制操作中始终对sql_require_primary_key系统变量使用值“ON”，在所有create和alter table操作中都需要主键。
- OFF：复制通道在复制操作中始终对sql_require_primary_key系统变量使用值“OFF” ，创建或更改表时不需要主键，即使主数据库强制执行了此类限制。
- STREAM：默认值，复制通道为每个事务使用从主数据库复制的值。这样可以保留以前的服务器行为。
用法和优点
第一个用例出现在对数据来源的主数据库没有严格控制的场景中。在这种情况下， REQUIRE_TABLE_PRIMARY_KEY_CHECK = ON可确保表定义中没有删除任何主键，不会导致性能问题。
在多源复制方案中，此功能也非常有用。使sql_require_primary_key的值保持一致，允许来自不同主数据库的复制通道之间的行为更加统一。当多个主数据库更新同一组表，并且其中一个表存在错误时，使用ON可以防止丢失主键。使用OFF可使多个主数据库一起工作而不管它们能否操作主键。
在复制通道中使用权限检查时，此功能也具有优势，因为将REQUIRE_TABLE_PRIMARY_KEY_CHECK设置为ON或OFF意味着具有PRIVILEGE_CHECKS_USER权限的帐户不再需要额外的权限来操作sql_require_primary_key。如果设置为STREAM，除了需要创建或更改表的基本权限外，还要求权限检查用户具有会话管理级别的权限用以复制查询。
配置
若要显式更改复制通道在处理主键检查策略的行为，您需要停止复制SQL线程。
可观察性
相关的Performance Schema表进行了功能增强，用以显示新的CHANGE MASTER TO…语句选项REQUIRE_TABLE_PRIMARY_KEY_CHECK的状态：
使用注意事项
此功能受RESET SLAVE ALL的影响，但不受RESET SLAVE的影响。
同样，虽然群组复制插件强制使用主键执行每个查询，但该检查不依赖于sql_require_primary_key并且限制较少。详情参阅“https://dev.mysql.com/doc/refman/8.0/en/group-replication-requirements.html”。
摘要
此功能是一种新工具，可在复杂多样的环境中保护您的复制流，同时您可以更好地控制复制用户的权限。
希望这项新功能可以使您利用MySQL创建更安全的解决方案。欢迎进行测试，并告诉我们您的意见。