网站建设维护宣传,自己建网站卖东西怎么样,陶瓷企业 瓷砖地板公司网站建设,网站优化公司效果本节列出和解释了组复制相关的要求和限制。1.组复制的要求要使用组复制#xff0c;每个MySQL节点必须满足以下条件#xff1a;1.1 基本要求InnoDB存储引擎#xff1a;数据必须存储在事务型的InnoDB存储引擎中。事务以乐观形式执行#xff0c;然后在提交前会检测冲突问题。如…本节列出和解释了组复制相关的要求和限制。1.组复制的要求要使用组复制每个MySQL节点必须满足以下条件1.1 基本要求InnoDB存储引擎数据必须存储在事务型的InnoDB存储引擎中。事务以乐观形式执行然后在提交前会检测冲突问题。如果有冲突为了维护组中一致性有些事务必须回滚。这意味着需要事务型的存储引擎。此外InnoDB 存储引擎提供了一些额外的功能它们结合组复制时能更好地管理和处理冲突。Primary Keys每张需要被组复制的表都必须显式定义一个主键。主键在判断事务是否冲突扮演极其重要的角色通过主键来准确识别每个事务中修改了表中的哪些行。(实际上是将主机hash成写集然后由certifier来并发事务之间的检测冲突性)使用IPv4 地址MySQL组复制使用的组通信引擎组件只支持 IPv4。因此必须使用IPv4的网络。良好的网络性能组复制设计的初衷是部署在集群环境中集群中的节点相互之间都非常近因此除了网络延迟网络带宽也会影响组复制。1.2 配置上的要求组中的每个成员都必须配置以下选项必须开启二进制日志设置--log-bin[log_file_name]。MySQL组复制会复制二进制日志的内容因此必须开启二进制日志。Slave Updates Logged设置--log-slave-updates。节点需要记录applier已应用的日志。组中的每个节点都需要记录它们所接收到并应用的所有事务这是必须的因为恢复过程是依赖于组中参与者的二进制日志来进行的。因此组中每个成员都必须保留每个事务的副本即使某事务不是在该节点上开始的。Row Format的二进制日志设置--binlog-formatrow。组复制依赖于基于行格式的二进制日志以便在组中传播所发生的更改能保持一致性。而且在探测组中不同节点间发生的并发事务是否冲突时需要从行格式的日志中提取一些内容来做比较。开启GTID复制设置--gtid-modeON。组复制使用GTID(全局事务ID)来精确跟踪每个节点上已经提交了哪些事务。也因此可以推断出某节点上要执行的事务是否和已执行的事务(每个节点上都有副本)冲突。换句话说GTID是整个组复制判断事务是否冲突的基础。Replication Information Repositories设置--master-info-repositoryTABLE和--relay-log-info-repositoryTABLE。applier需要将 master 和 relay log 的元数据信息写入到系统表 mysql.slave_master_info 和 mysql.slave_relay_log_info 中。这保证了组复制插件具有一致性恢复的能力和复制的元数据事务管理能力。Transaction Write Set Extraction设置--transaction-write-setextractionXXHASH64以便将行写入到二进制日志中时节点也收集写集。写集基于每行的主键是唯一标识被更改行的标签的简化形式该标签后续会用于探测事务冲突性。Multithreaded Appliers(某些旧版本没有该要求)可以将组复制成员配置为多线程appliers使得可以并行应用事务。需要设置--slave-parallel-workersN(N是applier线程数量)、--slavepreserve-commit-order1以及--slave-parallel-typeLOGICAL_CLOCK。--slaveparallel-workersN表示启用多applier线程组复制依赖于建立在所有参与节点都以相同顺序接收和应用、提交事务的一致性机制因此还必须设置--slave-preserve-commit-order1以保证并行事务的最终提交是和原事务所在顺序位置一致的。最后为了决定哪些事务可以并行执行relay log 必须包含由--slave-parallel-ypeLOGICAL_CLOCK生成的事务父信息(transaction parent information)。当尝试加入一个只设置了--slave-parallel-workers大于0却没有设置其他两项的新成员将会报错并阻止它的加入。2.组复制的限制(局限性)下面是使用组复制已知的限制Replication Event Checksums由于对复制事件校验的设计缺陷目前组复制不能使用它们。因此需要设置--binlog-checksumNONE。Gap Locks在验证阶段中(certification process)不会考虑 Gap Locks因此在 InnoDB 的外部无法获取任何关于Gap 锁的信息。注意:除非你的应用程序或业务需求依赖于REPEATABLE READ(MySQL默认该隔离级别)否则建议在组复制中使用READ COMMITTED隔离级别。在READ COMMITTED隔离级别中InnoDB基本上不会使用Gap Locks这将使得InnoDB自带的冲突探测能和组复制的冲突探测相互对齐从而保持一致。Table Locks and Named Locks验证阶段(certification process)中不考虑表锁和命名锁(见get_lock())。不支持 SERIALIZABLE 隔离级别在多主模型下默认不支持该隔离级别。如果在多主模型下设置了该隔离级别将拒绝提交事务。不支持并发的 DDL 和 DML 操作不支持在多主模型下不同节点上同时执行DDL和DML修改同一对象。在某节点上对某对象执行DDL语句时如果在其他节点同时执行DML修改该对象将有一定风险探测到冲突。(译注是 DDLDML 的并发DDLDDL 的并发也不允许。这是因为MySQL中没有DDL事务不能保证DDL的原子性当DDL和DML同时操作某一个对象可能DDL修改后DML将因为对象结构的改变而无法执行继而回滚)不支持级联的外键约束多主模型的组(所有节点都配置了group_replication_single_primary_modeOFF)不支持多级外键依赖特别是表上定义了级联的外键约束(CASCADING foreign key constraints)。这是因为多主模型下执行外键约束的级联操作可能会出现未检测到的冲突从而导致组内成员间数据不一致。因此我们推荐在使用多主模型时在每个节点上都设置group_replication_enforce_update_everywhere_checksON以避免出现未检测到的冲突。在单主模型下没有这种问题因为没有并发写操作从而不可能会出现未被探测到的冲突。大事务可能会错误如果一个事务非常大导致GTID的内容非常多以至于无法在 5 秒内通过网络传输完成这时组成员间的通信将失败。要避免该问题可以尽可能地限制事务的大小。例如将LOAD DATA INFILE的文件切割为多个小块。多主模型可能出现死锁在多主模型下SELECT ... FOR UPDATE语句可能会导致死锁。这是因为组内成员之间不会共享锁资源(译注share nothing)因此这样的语句可能达不到预期的结果。
