MK
摩柯社区 - 一个极简的技术知识社区
AI 面试

MariaDB与MySQL并行复制技术对比

2022-09-073.6k 阅读

MariaDB与MySQL并行复制技术基础概念

复制技术概述

在数据库领域，复制是一种将数据从一个数据库实例（主库）拷贝到一个或多个其他数据库实例（从库）的过程。这种技术对于实现数据冗余、提高可用性以及负载均衡至关重要。MySQL和MariaDB作为广泛使用的开源数据库管理系统，都提供了复制功能，并且随着发展，并行复制技术成为提升复制性能的关键手段。

MySQL并行复制技术

  1. 传统MySQL复制原理 MySQL传统复制基于单线程模型，主要分为三个步骤。首先，主库将数据库的更改记录到二进制日志（binlog）中。其次，从库通过I/O线程连接主库，读取主库的binlog，并将其写入到自己的中继日志（relay log）中。最后，从库的SQL线程从relay log中读取日志，并在从库上重放这些日志，从而使从库的数据与主库保持一致。这种单线程重放的方式在主库写入压力较大时，从库容易出现复制延迟。
  2. MySQL并行复制的演进 为了解决单线程复制的性能瓶颈，MySQL引入了并行复制技术。MySQL 5.6版本引入了基于库（database）的并行复制，即不同库的事务可以在从库上并行重放。其原理是通过在主库的binlog中添加库的信息，从库的SQL线程根据库信息将事务分配到不同的worker线程中执行。例如，假设有两个库db1和db2，当从库接收到关于db1和db2的事务日志时，会将db1相关事务交给一个worker线程，db2相关事务交给另一个worker线程，从而实现并行处理。代码示例如下：
-- 在主库配置
log-bin=mysql-bin
server-id=1

-- 在从库配置
server-id=2
relay-log=relay-bin
read-only=1
-- 开启基于库的并行复制
slave-parallel-type=DATABASE
slave-parallel-workers=4

MySQL 5.7版本进一步改进，引入了基于逻辑时钟（Logical Clock）的并行复制，也称为GTID（Global Transaction Identifier）并行复制。GTID是一个全局唯一的事务标识符，它由主库的UUID和事务ID组成。在基于GTID的并行复制中，从库通过GTID来判断事务之间的依赖关系，只要事务之间没有依赖关系，就可以并行重放。例如，假设有事务T1和T2，它们在不同的数据行上进行操作且无依赖，从库可以同时重放这两个事务。

-- 在主库配置
log-bin=mysql-bin
server-id=1
gtid-mode=ON
enforce-gtid-consistency=ON

-- 在从库配置
server-id=2
relay-log=relay-bin
read-only=1
gtid-mode=ON
enforce-gtid-consistency=ON
slave-parallel-type=LOGICAL_CLOCK
slave-parallel-workers=4

MariaDB并行复制技术

  1. MariaDB传统复制原理 MariaDB的传统复制机制与MySQL类似，同样依赖于主库的binlog记录和从库的I/O线程、SQL线程。主库将变更记录到binlog，从库I/O线程获取binlog写入relay log，SQL线程重放relay log中的日志。然而，MariaDB在一些细节上有所不同，例如其binlog格式在某些版本中有优化，以提高复制效率。
  2. MariaDB并行复制的特点 MariaDB提供了多种并行复制策略。一种是基于组提交（Group Commit）的并行复制。在主库上，事务会被分组提交，组内的事务可以在从库上并行重放。其原理是利用主库提交事务时的组提交特性，在binlog中记录组提交的信息，从库根据这些信息并行执行组内事务。例如，主库上有事务T1、T2、T3在同一组提交，从库可以同时重放这三个事务。
-- 在主库配置
log-bin=mysql-bin
server-id=1
-- 开启组提交相关优化
innodb_flush_log_at_trx_commit=2
sync_binlog=0

-- 在从库配置
server-id=2
relay-log=relay-bin
read-only=1
-- 开启基于组提交的并行复制
slave_parallel_threads=4

MariaDB还支持基于行（row）的并行复制。这种方式下，从库会分析行数据的修改情况，只要不同事务修改的行不冲突，就可以并行执行。例如，事务T1修改表table1的第一行，事务T2修改table1的第三行，且这两个事务无其他依赖关系，从库可以并行执行这两个事务。

并行复制技术的性能对比

测试环境搭建

  1. 硬件环境 使用三台配置相同的服务器，每台服务器配备8核CPU、16GB内存、500GB SSD硬盘。操作系统为CentOS 7.9，网络带宽为1000Mbps。
  2. 软件环境 在其中一台服务器上安装MySQL 8.0和MariaDB 10.6，分别作为MySQL和MariaDB的主库。另外两台服务器分别安装MySQL 8.0和MariaDB 10.6作为从库。配置主从复制，确保MySQL和MariaDB的复制环境正常运行。
  3. 测试数据准备 创建一个包含100张表的数据库，每张表有10000条记录。使用sysbench工具对数据库进行读写操作，模拟实际生产环境中的负载。

性能测试场景

  1. 高并发写入场景 使用sysbench工具以100个并发线程对主库进行写入操作，持续10分钟。记录从库的复制延迟时间和吞吐量。在MySQL中，由于基于库或GTID的并行复制，不同库或无依赖事务的并行执行，在高并发写入时，从库能够较快地跟上主库的节奏。例如，在测试中，如果多个写入事务分别涉及不同的库，基于库的并行复制可以让从库迅速将这些事务分配到不同worker线程执行。而MariaDB基于组提交和行的并行复制，在高并发写入时，组内事务和无冲突行的事务并行执行，也能有效减少复制延迟。在一些测试场景下，MariaDB基于组提交的并行复制在高并发写入时吞吐量比MySQL基于库的并行复制提高了约20%，因为组提交减少了事务提交的开销，使得从库可以更高效地重放事务。
  2. 混合读写场景 使用sysbench工具以50个并发线程进行写入操作，50个并发线程进行读取操作，持续10分钟。同样记录从库的复制延迟时间和吞吐量。在这种场景下，MySQL的并行复制需要协调读写操作对复制的影响，基于GTID的并行复制在判断事务依赖关系时，要考虑读操作可能带来的一致性问题。而MariaDB基于行的并行复制在混合读写场景中有一定优势，因为它可以更细粒度地判断行数据的冲突，对于读操作影响较小，能够在保证数据一致性的前提下，提高复制的并行度。例如，在一次测试中，MariaDB在混合读写场景下的复制延迟比MySQL低约15%，这得益于其基于行的并行复制策略对读写操作的更好协调。

性能差异分析

  1. 架构设计差异 MySQL的并行复制更多基于事务的逻辑关系，如基于库和基于GTID的方式，通过判断事务间的依赖关系来实现并行。而MariaDB的并行复制策略更注重底层数据结构，如基于组提交和行的方式，从更细粒度的层面提高并行度。这种架构设计上的差异导致在不同场景下性能表现不同。在事务涉及多个库且库间事务依赖较少的场景，MySQL基于库的并行复制能发挥较好性能；而在事务对行数据操作较为频繁且行冲突较少的场景，MariaDB基于行的并行复制更具优势。
  2. 日志处理方式 MySQL的binlog格式和处理方式在并行复制中，主要为了支持事务的逻辑并行。例如，GTID的引入使得事务在主从库间的追踪和并行执行更清晰。而MariaDB的binlog在支持并行复制时，更注重与组提交和行操作的结合。在组提交场景下，MariaDB的binlog能更好地记录组内事务信息，便于从库并行重放。这种日志处理方式的差异，影响了并行复制时的效率和性能稳定性。例如，在高并发事务提交场景下，MariaDB基于组提交的binlog处理方式能减少日志I/O开销，从而提高并行复制性能。

数据一致性保证对比

MySQL并行复制的数据一致性

  1. 基于库并行复制的数据一致性 在MySQL基于库的并行复制中，由于不同库的事务并行执行，只要库之间没有数据依赖关系，数据一致性能够得到较好保证。例如，库db1和db2相互独立，分别在这两个库上进行的事务并行执行不会导致数据一致性问题。然而，如果存在跨库事务，基于库的并行复制可能会出现问题。比如，一个事务需要在db1和db2中同时插入关联数据，若两个库的事务并行执行顺序不当，可能会导致数据不一致。为了解决这个问题，MySQL引入了XA事务支持，通过分布式事务协调机制来保证跨库事务的一致性。
  2. 基于GTID并行复制的数据一致性 基于GTID的并行复制通过全局唯一的事务标识符，能够更准确地判断事务之间的依赖关系。从库在重放事务时，依据GTID确保事务按照主库的顺序执行，从而保证数据一致性。例如，即使主库上有多个并发事务，从库通过GTID可以正确地并行重放这些事务，不会出现由于事务顺序错乱导致的数据不一致问题。但是，在一些特殊场景下，如主库在短时间内大量写入事务且网络存在波动时，从库可能会因为接收GTID信息不完整或处理延迟，导致短暂的数据不一致，但这种情况在网络稳定和系统负载正常时很少发生。

MariaDB并行复制的数据一致性

  1. 基于组提交并行复制的数据一致性 MariaDB基于组提交的并行复制，由于事务在主库是分组提交的，从库按照组的顺序重放事务，在很大程度上保证了数据一致性。组内事务并行执行，但组与组之间是顺序执行的，这就避免了由于事务无序执行导致的数据不一致。例如，主库上一组事务T1、T2、T3提交，从库会先并行执行完这组事务，再执行下一组事务，确保了事务的逻辑顺序。然而，如果组提交的配置不当，如组的划分不合理或者组内事务存在复杂的依赖关系，可能会影响数据一致性。比如，组内事务T1依赖于T2的结果，但从库并行执行时先执行了T1，就可能导致数据不一致。因此，合理配置组提交参数对于保证数据一致性至关重要。
  2. 基于行并行复制的数据一致性 MariaDB基于行的并行复制通过分析行数据的冲突来保证数据一致性。只有当不同事务修改的行不冲突时，才会并行执行。例如，事务T1修改表table1的第一行，事务T2修改table1的第三行，这两个事务可以并行执行且不会导致数据不一致。但是，如果两个事务都要修改同一行数据，基于行的并行复制会按照一定的锁机制顺序执行，确保数据一致性。然而，在高并发场景下，行锁的竞争可能会导致性能下降，同时，如果锁机制处理不当，也可能出现死锁等影响数据一致性的问题。

数据一致性保障措施对比

  1. 锁机制对比 MySQL在并行复制中，主要通过数据库级别的锁来保证数据一致性。例如，在基于库的并行复制中，对于跨库事务，会使用XA事务锁来协调不同库之间的操作。在基于GTID的并行复制中，通过GTID的顺序保证事务执行顺序，减少锁的竞争。而MariaDB在并行复制中，除了数据库级别的锁，还引入了更细粒度的行锁。在基于行的并行复制中，行锁用于防止并行执行的事务对同一行数据产生冲突。这种细粒度的锁机制在一定程度上提高了并行度，但也增加了锁管理的复杂性。在高并发场景下，MySQL的数据库级锁可能导致锁争用严重，而MariaDB的行锁虽然能减少锁争用范围，但行锁的频繁获取和释放也会带来一定的性能开销。
  2. 事务协调机制对比 MySQL通过XA事务协调机制来处理跨库事务，保证不同库之间事务的一致性。在基于GTID的并行复制中，GTID本身就是一种事务协调机制，从库依据GTID重放事务。MariaDB在基于组提交的并行复制中，通过组提交信息来协调事务的并行执行，保证组内和组间事务的顺序。在基于行的并行复制中，通过行冲突检测和锁机制来协调事务。总体而言，MySQL的事务协调机制更侧重于事务的逻辑层面，而MariaDB的事务协调机制更侧重于底层数据操作层面，两者在不同场景下各有优劣。

应用场景适用性对比

MySQL并行复制的应用场景

  1. 多库架构应用场景 在具有多库架构的应用中，MySQL基于库的并行复制非常适用。例如，一个大型电商系统，将用户信息存储在user_db库，商品信息存储在product_db库，订单信息存储在order_db库。由于不同库之间的数据独立性较高，基于库的并行复制可以让从库高效地并行重放不同库的事务，提高复制性能。同时，对于一些对数据一致性要求不是特别高，允许一定时间内不同库之间数据存在微小差异的场景，基于库的并行复制能满足需求。在这种场景下，配置基于库的并行复制，设置合适的slave-parallel-type和slave-parallel-workers参数，可以有效提升从库的复制效率。
  2. 数据仓库应用场景 在数据仓库应用中，MySQL基于GTID的并行复制具有优势。数据仓库通常需要从多个数据源抽取数据，进行清洗、转换和加载（ETL）。MySQL主库接收来自不同数据源的事务，基于GTID的并行复制可以确保从库准确地并行重放这些事务，保证数据一致性。例如，在一个金融数据仓库中，主库接收来自交易系统、客户管理系统等多个数据源的事务，从库通过GTID并行复制可以快速同步数据，为数据分析提供准确的数据基础。同时，GTID的全局唯一性使得数据仓库在进行数据追溯和故障恢复时更加方便。

MariaDB并行复制的应用场景

  1. 高并发OLTP应用场景 在高并发在线事务处理（OLTP）应用中，MariaDB基于组提交和行的并行复制表现出色。例如，在一个在线支付系统中，大量的支付事务并发处理。MariaDB基于组提交的并行复制可以将并发的支付事务分组提交，从库并行重放组内事务，减少复制延迟。基于行的并行复制可以让无冲突的支付事务并行执行，提高系统的并发处理能力。在这种场景下，合理配置MariaDB的组提交参数和行并行复制参数，如innodb_flush_log_at_trx_commit、sync_binlog、slave_parallel_threads等，可以显著提升系统性能。
  2. 对数据一致性要求极高的应用场景 对于对数据一致性要求极高的应用，如银行核心业务系统，MariaDB基于行的并行复制能更好地保证数据一致性。在银行转账等业务中，每一笔交易都涉及对账户余额等关键数据的修改，基于行的并行复制通过精确的行冲突检测和锁机制，确保同一行数据在同一时间只有一个事务能修改，从而保证数据的准确性和一致性。同时，MariaDB基于组提交的并行复制也能保证事务的顺序执行，进一步提高数据一致性。在这种场景下，虽然行锁可能会带来一定的性能开销，但为了保证数据的绝对准确，这种开销是可以接受的。

场景选择建议

  1. 性能优先场景 如果应用场景对性能要求极高，且数据一致性要求相对宽松，如一些实时数据分析的缓存场景，MySQL基于库的并行复制或MariaDB基于组提交的并行复制可能是较好的选择。MySQL基于库的并行复制在多库架构下能快速并行处理事务，而MariaDB基于组提交的并行复制在高并发写入场景下有较高的吞吐量。在这种场景下，可以根据具体的业务架构和负载特点，选择合适的数据库和并行复制策略，并通过调优参数来进一步提升性能。
  2. 一致性优先场景 当应用场景对数据一致性要求极高，如金融、医疗等领域的关键业务系统，MariaDB基于行的并行复制结合组提交并行复制更为合适。虽然这种方式可能在性能上有所牺牲，但通过细粒度的行冲突检测和事务顺序保证，能最大程度地确保数据的一致性。同时，MySQL基于GTID的并行复制在一些对一致性要求高且事务逻辑较为清晰的场景下也可以考虑，通过合理配置GTID相关参数，保证事务的准确重放。在选择时，需要综合考虑业务对一致性的严格程度和可接受的性能损耗。

可扩展性对比

MySQL并行复制的可扩展性

  1. 从库数量扩展 在MySQL并行复制中，随着从库数量的增加，系统的可扩展性面临一定挑战。基于库的并行复制在从库数量增多时，由于不同从库对主库binlog的读取和处理能力不同，可能会出现部分从库复制延迟的情况。例如，当有10个从库时，可能其中几个从库因为硬件性能或网络问题，无法及时跟上主库的更新速度。基于GTID的并行复制虽然在一定程度上改善了这种情况，但随着从库数量进一步增加，主库与从库之间的GTID信息交互开销也会增大。当从库数量达到20个以上时，主库需要花费更多资源来维护与从库的GTID同步，可能导致主库性能下降，从而影响整个系统的可扩展性。
  2. 负载均衡扩展 MySQL并行复制在负载均衡扩展方面，主要依赖于从库的读负载分担。从库可以处理读请求，减轻主库的压力。然而，在并行复制过程中，由于从库需要重放主库的事务日志，可能会出现从库复制延迟导致读数据不一致的问题。为了解决这个问题，通常会采用一些中间件来进行负载均衡和数据一致性保证。例如，使用MyCAT等中间件，它可以根据从库的复制状态动态分配读请求，尽量避免读取复制延迟较大的从库数据。但这种方式增加了系统的复杂性，且中间件本身也可能成为性能瓶颈，限制了系统的可扩展性。

MariaDB并行复制的可扩展性

  1. 从库数量扩展 MariaDB基于组提交和行的并行复制在从库数量扩展方面表现较好。基于组提交的并行复制，由于组内事务的并行执行，从库可以更高效地处理主库的事务日志。即使从库数量增加，只要硬件资源足够，从库能够保持较高的复制性能。例如，在一个拥有15个从库的系统中，MariaDB基于组提交的并行复制能够使各个从库相对均衡地处理事务，复制延迟相对较小。基于行的并行复制在从库数量增多时，通过细粒度的行冲突检测和并行执行，也能保证从库的复制效率。但是，当从库数量过多时，如超过30个，主库与从库之间的通信开销以及从库自身的资源管理压力会增大，可能会对可扩展性产生一定影响。
  2. 负载均衡扩展 在负载均衡扩展方面，MariaDB同样依赖从库分担读负载。但与MySQL不同的是，MariaDB基于行的并行复制可以在保证数据一致性的前提下，更好地处理读请求。因为基于行的并行复制能够更细粒度地控制事务执行，减少读数据不一致的情况。同时，MariaDB的一些扩展工具，如MaxScale，能够更智能地进行负载均衡。MaxScale可以根据从库的负载情况、复制状态等因素，动态分配读请求，提高系统的整体性能和可扩展性。例如，MaxScale可以将读请求优先分配到复制延迟小且负载低的从库，从而提高系统的并发处理能力。

可扩展性优化建议

  1. 硬件资源优化 无论是MySQL还是MariaDB，在扩展从库数量时，都需要合理配置硬件资源。确保从库有足够的CPU、内存和磁盘I/O能力来处理主库的事务日志。例如，对于高负载的从库，可以增加CPU核心数、扩大内存容量以及使用高性能的SSD硬盘，提高从库的复制性能。同时，优化网络配置，减少主从库之间的网络延迟，也是提高可扩展性的关键。可以采用高速网络设备、优化网络拓扑结构等方式，确保主从库之间的数据传输顺畅。
  2. 软件配置优化 在软件配置方面，MySQL可以通过合理调整并行复制参数，如slave-parallel-workers，根据从库的硬件资源和负载情况，设置合适的worker线程数量。同时，优化GTID相关配置，减少主从库之间的GTID同步开销。对于MariaDB，要合理配置组提交参数，如innodb_flush_log_at_trx_commit和sync_binlog，平衡事务提交的性能和数据安全性。在使用扩展工具时，如MySQL的MyCAT和MariaDB的MaxScale，要根据系统特点进行详细配置，提高负载均衡的效率和准确性，从而提升系统的可扩展性。