Mysql8.4参考手册走读（六）

吴代庄

于 2024-07-17 07:30:00 发布

阅读量538

点赞数 16

分类专栏： # 组件文章标签：数据库 mysql

本文链接：https://blog.csdn.net/Luck_gun/article/details/140479612

版权

组件专栏收录该内容

27 篇文章 0 订阅

订阅专栏

第19章复制

19.4 复制解决方案

19.4.1 使用复制进行备份

若要使用复制作为备份解决方案，请从源到副本进行操作，然后备份副本。副本可以暂停和关闭，不影响源，因此您可以生成“实时”数据的有效快照，否则将需要源被关闭。

备份数据库的方式取决于数据库的大小以及是否仅备份数据，或在发生故障时可以重建副本的备份数据和副本状态。因此，有两种选择：

如果使用复制作为解决方案，使您能够备份源上的数据以及数据库的大小不是太大，mysqldump工具可能合适。请参见第19.4.1.1节“使用mysqldump备份副本”。
对于较大的数据库，mysqldump将不切实际或效率低下，您可以备份原始数据文件。使用原始数据文件选项还意味着您可以备份二进制和中继日志，在出现副本失败时可以重新创建副本。有关更多信息，请参见第19.4.1.2节“从副本备份原始数据”。

另一种备份策略，可用于源或副本服务器，是将服务器置于只读状态。这种备份是针对只读服务器执行的，然后已更改回其通常的读/写操作状态。请参见第19.4.1.3节“通过将源或副本设置为只读来备份源或副本”。

19.4.1.1 使用 mysqldump 备份副本

在您使用mysqldump进行数据库备份时，为了确保转储包含的数据一致，建议在开始转储过程之前停止副本上的复制处理。以下是操作步骤的整理：

停止副本处理请求：
- 您可以使用mysqladmin命令完全停止副本上的复制处理：
```
$> mysqladmin stop-replica
```
- 或者，您也可以只停止复制SQL线程，以暂停事件的执行：
```
$> mysql -e 'STOP REPLICA SQL_THREAD;'
```
这样做可以让副本继续接收数据更改事件，并将它们存储在中继日志中，但阻止副本执行这些事件并更改其数据。
运行mysqldump以转储数据库：
- 您可以选择转储所有数据库或特定的数据库。例如，要转储所有数据库，请执行以下命令：
```
$> mysqldump --all-databases > fulldb.dump
```
转储完成后，重新启动复制：
- 使用mysqladmin命令重新启动复制：
```
$> mysqladmin start-replica
```
在执行上述操作时，可能需要添加登录凭据（用户名、密码）到命令中，并将这些步骤集成到一个脚本中，以便可以每天自动运行。
如果采用此方法，请确保监控复制过程，以确保运行备份所花费的时间不会影响副本跟上源事件的能力。

19.4.1.2 从副本备份原始数据

整理后的文本：

为了确保复制的文件的完整性，在备份MySQL副本服务器时，应该在服务器关闭的状态下进行。如果MySQL服务器仍在运行，后台任务可能仍在更新数据库文件，尤其是那些涉及具有后台进程的存储引擎的文件。这些问题应该在崩溃恢复期间解决，但由于副本服务器可以在备份过程中关闭，而不会影响源服务器的执行，利用这一点是有意义的。

要关闭服务器并备份文件，可以按照以下步骤操作：

关闭副本MySQL服务器：
```
$> mysqladmin shutdown
```
复制数据文件。您可以使用任何合适的复制或存档实用程序，包括 cp、tar 或 WinZip。例如，假设数据目录位于当前目录，可以存档整个目录如下：
```
$> tar cf /tmp/dbbackup.tar ./data
```

再次启动MySQL服务器。在 Unix 下：

$> mysqld_safe &

在 Windows 下：

C:\> "C:\Program Files\MySQL\MySQL Server 8.4\bin\mysqld"

通常，您应该备份整个数据目录副本MySQL服务器。如果希望能够还原数据并作为副本运行（例如，在发生故障时的副本），除了数据之外，您还需要拥有副本的连接元数据存储库和应用元数据存储库和中继日志文件。这些项目需要在还原副本的数据后恢复复制。

假设表已用于副本的连接元数据存储库和应用元数据存储库（参见第 19.2.4 节 “中继日志和复制元数据存储库”），这是 MySQL 中的默认设置 8.4，这些表与数据一起备份目录。如果文件已用于存储库，则已弃用，则必须单独备份这些内容。中继日志如果文件已放置在数据目录的不同位置。

如果您丢失了中继日志，但仍有该文件，您可以将其检查到确定复制 SQL 线程在源的二进制日志。然后，您可以将 CHANGE REPLICATION SOURCE 与将副本告知的 AND 选项从那时起重新读取二进制日志。这要求二进制日志仍存在于源服务器上。

如果复制副本正在复制 LOAD DATA 语句，您还应该备份副本用于此目的的目录。副本需要这些文件来恢复任何中断的 LOAD DATA 操作的复制。此目录的位置是系统变量 replica_load_tmpdir 的值。如果服务器未使用该变量集启动，即目录位置是 TMPDIR 系统变量的值。

19.4.1.3 通过将源或副本设置为只读来备份源或副本

如何在MySQL中安全地执行备份操作

在进行数据库备份时，确保数据的一致性和完整性是至关重要的。为此，可以通过设置服务器为只读模式来实现。以下是详细的步骤和注意事项。

1. 使服务器进入只读模式

要使MySQL服务器进入只读模式，可以按照以下步骤操作：

获取全局读取锁。
将 read_only 系统变量设置为 ON。

mysql> FLUSH TABLES WITH READ LOCK;
mysql> SET GLOBAL read_only = ON;

这样设置后，服务器只会处理检索请求，并阻止所有更新操作。

2. 执行备份

当服务器处于只读模式时，可以安全地执行备份操作，例如使用 mysqldump 工具。

3. 恢复服务器到正常读写模式

完成备份后，应立即将服务器恢复到正常的读写模式：

mysql> SET GLOBAL read_only = OFF;
mysql> UNLOCK TABLES;

注意事项

上述操作确保了在备份期间，服务器不会处理任何更新操作，从而避免了数据不一致的问题。
但是，这种方法并不适用于通过复制进行的二进制备份，因为可能存在未刷新到磁盘的修改数据。
在复制环境中，需要特别注意只对源或副本中的一个执行此操作，以避免影响到整个复制网络。

特定场景

场景1：备份源服务器

当源服务器 S1 设置为只读时：

连接到 S1 的客户端 C1 的更新请求会被阻止。
查询结果请求会成功。
在 S1 上进行备份是安全的。

场景2：备份副本服务器

当副本服务器 R1 设置为只读时：

源服务器 S1 继续正常运行，但在源头进行备份不安全。
在副本 R1 上进行备份是安全的。
客户端 C2 仍然可以对源服务器执行更新。

通过遵循这些步骤和注意事项，可以在不影响正常操作的情况下，安全地对MySQL服务器进行备份。

19.4.2 处理副本的意外停止

为了使复制能够对意外停止的服务器（有时被描述为崩溃安全）进行恢复，副本必须在停止之前恢复其状态。本节描述了在复制过程中副本的状态，以及如何配置副本以获得最佳恢复机会。

在副本意外停止后，重新启动复制SQL线程必须恢复有关哪些事务已执行的信息。这些恢复所需的资料存储在副本的应用元数据存储库中。默认情况下，此存储库创建为名为mysql.slave_relay_log_info的InnoDB表。通过使用这个事务存储引擎，信息始终是可恢复的。对应用元数据存储库的更新与事务一起提交，这意味着副本在该存储库中记录的进度信息始终与应用于数据库的内容保持一致，即使在服务器意外停止的情况下。

复制副本从意外停止中的恢复过程因配置而异。恢复的总体目标是确定哪些事务已应用于副本数据库，以及检索并应用在意外停止之后遗漏的事务。对于基于GTID的复制，恢复过程需要已收到的事务的GTID或由副本提交的GTID。对于基于文件位置的复制，恢复过程需要准确的复制SQL线程（应用者）位置，显示在副本上应用的最后一个事务。

以下设置组合适用于不同类型的副本，以保证在复制控制下的恢复：

使用基于GTID的复制时，设置gtid_mode=ON和SOURCE_AUTO_POSITION=1，这将激活GTID自动定位，用于连接源自动识别和检索丢失的事务。
设置sync_relay_log=1，指示复制接收器线程在写入每个接收的事务后将日志同步到磁盘。
设置innodb_flush_log_at_trx_commit=1，在提交每个事务之前将InnoDB日志同步到磁盘。
设置relay_log_info_repository = TABLE，用于存储复制SQL线程的位置，并确保记录始终准确无误。
设置relay_log_recovery = ON，实现自动中继日志恢复。

以上设置可以确保在副本意外停止时的复制恢复过程顺利进行。

19.4.3 监视基于行的复制

下文整理：

复制应用程序（SQL）线程的当前进度可以通过使用基于行的复制进行性能监控。这种模式仪器阶段使您能够跟踪操作并检查已完成的工作量和工作量估计。当这些性能架构仪器阶段已启用时，events_stages_current表将显示应用线程的阶段及其进度。有关背景信息，请参阅第29.12.5节“性能架构阶段事件表”。

为了跟踪所有三种基于行的复制事件类型（写入、更新、删除）的进度，需要通过发出以下命令来启用三个性能架构阶段：

mysql> UPDATE performance_schema.setup_instruments SET ENABLED = 'YES'
    -> WHERE NAME LIKE 'stage/sql/Applying batch of row changes%';

等待复制处理某些事件的应用线程，然后通过查看events_stages_current表来检查进度。例如，要获取更新事件的进度，可以执行以下查询：

mysql> SELECT WORK_COMPLETED, WORK_ESTIMATED FROM performance_schema.events_stages_current
    -> WHERE EVENT_NAME LIKE 'stage/sql/Applying batch of row changes (update)';

如果启用了binlog_rows_query_log_events，则有关查询的信息将存储在二进制日志文件中，并在现场公开。要查看触发此事件的原始查询，请执行以下操作：

mysql> SELECT db, processlist_state, processlist_info FROM performance_schema.threads
    -> WHERE processlist_state LIKE 'stage/sql/Applying batch of row changes%' AND thread_id = N;

19.4.4 使用不同源和副本存储引擎的复制

对于复制过程来说，源上的原始表和副本是否使用不同的存储引擎类型取决于如何设置初始复制过程。如果您使用mysqldump创建数据库快照，可以编辑转储文件以更改每个表上使用的引擎类型。另一种选择是禁用您不想在复制副本中使用的引擎，然后使用转储来创建副本。如果使用原始数据文件（二进制备份）来设置副本，则无法更改初始表格式。对于新的源/副本复制设置，避免指定引擎创建新表时键入。

如果您已经在运行复制解决方案，并且想要将现有表格转换为其他引擎类型，请遵循以下操作步骤：停止副本运行复制更新；执行ALTER TABLE … ENGINE='engine_type’语句，为每个表更改引擎类型；再次启动复制过程。虽然default_storage_engine变量不会被复制，但请注意CREATE TABLE和ALTER TABLE语句将被复制到副本中。如果在CSV表的情况下，您执行ALTER TABLE语句，表的引擎类型将被复制到副本中，即使之前已将副本上的表类型更改为其他引擎。如果想保留源和副本之间的引擎差异，应小心创建新表时使用default_storage_engine变量。

19.4.5 使用复制进行横向扩展

因为复制工作原理是从一个源的分布到一个或多个副本，使用复制进行横向扩展效果最佳在读取次数高且读取次数少的环境中写入/更新次数。大多数网站都属于这一类，用户浏览网站、阅读文章、帖子或查看产品。更新仅在会话管理期间发生，或者在进行购买或向论坛添加评论/消息时。

19.4.6 将不同的数据库复制到不同的副本

可以通过配置源和副本，然后限制二进制日志语句每个副本都使用每个副本上的 --replicate-wild-do-table 配置选项进行处理。

19.4.7 提高复制性能

整理后的文本：

为了提高复制过程的性能，可以采用创建更深层次的复制结构的方法。在这种结构中，源服务器仅复制到一个副本，而其他副本则连接到这个主副本以满足复制要求。图19.3“Using an Additional Replication Source to Improve Performance”展示了这种结构的示例。

在这个例子中，MySQL源服务器1复制到MySQL源服务器2，然后MySQL源服务器2复制到MySQL副本服务器1、MySQL副本服务器2和MySQL副本服务器3。

要实现这一点，您需要将MySQL实例配置为遵循以下规则：

源服务器1是所有更改和更新的主要来源，写入数据库。两个源服务器都启用了二进制日志记录，这是默认设置。
源服务器2是源服务器1的副本，它提供了将数据复制到复制结构中的其余副本的功能。源服务器2是唯一允许连接到源服务器1的机器。源服务器2已启用–log-replica-updates选项（默认值）。使用此选项时，从源服务器1复制的指令也会写入源服务器2的二进制日志，以便可以将它们复制到真正的副本。
副本服务器1、副本服务器2和副本服务器3充当源服务器2的副本，并复制源服务器2中的信息，这些信息实际上由源服务器1上记录的更新组成。

这种解决方案可以减少客户端负载和网络接口负载在主源上的负担，从而改善作为直接数据源的主源的整体性能。

如果您的副本无法跟上复制过程中的源代码，有多种选项可供选择：

如果可能，请将继电器日志和数据文件放在不同的物理驱动器上。为此，请将relay_log系统变量设置为指定中继日志的位置。
如果读取二进制日志文件的磁盘I/O活动繁重并且中继日志文件是一个问题，请考虑增加rpl_read_size系统变量的值。此系统变量控制从日志文件中读取的数据量，增加它可能会减少当文件数据当前不在操作系统缓存中时的文件读取和I/O停止。请注意，为此值分配的大小适用于包括副本上的源和协调器线程在内的二进制日志和中继日志文件。因此，设置较大的值可能会对服务器产生影响。
如果副本明显慢于源，则可能希望分担复制的责任，将不同的数据库转换为不同的副本。请参见第19.4.6节“将不同的数据库复制到不同的副本”。
如果您的来源使用事务而您不担心副本上的事务支持或使用其他非事务引擎，请参见第19.4.4节“使用不同源和副本存储引擎的复制”。MyISAM
如果你的副本不充当源，并且你有一个潜在的解决方案到位，以确保如果发生故障，你可以禁用log_replica_updates。这防止“哑”副本也将它们已经执行的事件记录到自己的二进制日志中。

19.4.8 故障转移期间切换源

在故障转移期间，您需要将副本的源更改为新的源。这可以通过使用 CHANGE REPLICATION SOURCE TO 语句来实现。请注意，副本不会检查新源与当前源是否兼容，而是直接从新源的二进制日志开始。

在进行故障转移时，所有组中的服务器通常执行相同的事件和相同的二进制日志文件，因此更改事件来源不应影响数据库的结构和完整性。但是，在执行此操作时，您需要特别小心。

为了确保副本可以在不重新启动 MySQLD 的情况下成为源，您需要确保副本启用了二进制日志记录（通过 --log-bin 选项）。如果不使用 GTID 进行复制，则还应将 --log-replica-updates 设置为 OFF（默认情况下为 ON）。这样，副本就准备好在故障转移期间切换源了。

19.4.9 使用异步连接故障切换源和副本

异步连接故障转移机制可用于建立源到副本的异步复制，并在从副本到其源的连接失败时保留副本与多个MySQL服务器或服务器组同步共享数据。潜在源服务器列表存储在副本中，如果连接失败，则新源是根据您设置的加权优先级从列表中选择的。

异步连接故障转移机制还支持组复制拓扑，通过自动监视组成员身份和区分主要和次要服务器。将组成员添加到源列表并定义它作为托管组的一部分，即异步连接故障转移机制更新源列表以使其与成员身份更改、添加和删除组成员当他们加入或离开时自动。仅限在线群组成员大多数用于连接和获取地位。托管组的最后一个剩余成员不会即使它离开组也会自动删除，以便将保留受管组的配置。但是，您可以手动删除该组如果不再需要托管组。

异步连接故障转移机制还支持属于托管复制组的副本自动重新连接到发送方，如果当前接收器（组的主要）失败。此功能适用于组复制，在配置为单主模式的组上，其中该组的主副本是具有复制通道的副本使用该机制。该功能专为一组发送方和一组接收方与每个接收方保持同步其他即使某些成员暂时不可用。它还将领一组接收方与一个或多个发送方同步不属于托管组。不属于复制组不能使用此功能。

使用异步连接故障转移的要求机制如下：

必须在源和复本上使用GTID(gtid_mode=ON),并且必须在复本上启用CHANGE REPLICATION SOURCE TO语句的选项，以便GTID自动定位用于连接到源。SOURCE_AUTO_POSITION

必须存在相同的复制用户帐户和密码通道的源列表中的所有源服务器。此帐户用于连接到每个来源。您可以为不同的帐户设置不同的帐户渠道。

必须向复制用户帐户授予对性能架构表的权限，例如，通过发出SELECTGRANT SELECT ON performance_schema.* TO ‘repl_user’;

无法指定复制用户帐户和密码在用于开始复制的语句上，因为它们需要在自动重启时可用，以便连接到替代来源。必须使用更改复制源TO语句，并记录在复制元数据存储库。

如果异步连接故障转移的通道正在使用的机制位于组复制的主节点上单主模式组，异步连接故障切换默认情况下，副本之间也处于活动状态。在这种情况下，复制通道和复制用户帐户，以及必须在所有辅助通道上设置通道的密码复制组中的服务器，以及任何新加入的服务器成员。如果新服务器是使用MySQL的克隆功能，这一切都会自动发生。

19.4.10 半同步复制

MySQL 8.4 支持由插件实现的半同步复制，这是除了内置的异步复制之外的另一种复制方式。默认情况下，MySQL 复制是异步的，源服务器将事件写入其二进制日志，而副本在请求时才准备这些事件。这意味着源服务器不知道副本是否或何时检索并处理了交易，并且没有任何保证任何事件都到达任何副本。因此，如果源崩溃，它已提交的事务可能尚未传输到任何副本。在这种情况下，从源故障转移到副本可能会导致故障转移到缺少事务的服务器。

完全同步复制是一种更强的保证，当源提交事务时，所有副本也都提交了事务。这意味着任何时候都可以从源到任何副本。但是，完全同步复制的缺点是可能会有很多延迟完成交易。

半同步复制介于异步复制和完全同步复制之间。源会等到至少一个副本已接收并记录事件（所需数量的副本是可配置的），然后提交事务。这意味着半同步复制保证，如果源崩溃，它提交的所有事务都已传输到至少一个副本。

与异步复制相比，半同步复制提供改进的数据完整性，因为当提交返回成功时，已知数据至少存在于两个地方。与完全同步复制相比，半同步复制速度更快，因为它可以配置为平衡您对数据完整性的要求（副本数确认收到交易）的速度和提交的速度，由于需要等待副本而较慢。

使用半同步复制时，如果源崩溃且故障转移到副本时，故障源应不能重用为复制源，并且应该丢弃。它可能具有未确认的交易，由任何副本在故障转移时处理。如果您的目标是实现容错复制所有服务器接收相同事务的拓扑相同的顺序，崩溃的服务器可以重新加入组并自动更新，您可以使用组复制来实现这一点。

与半同步复制相比，半同步复制对性能的影响是增加数据的完整性。减速量至少是TCP/IP往返将提交发送到副本并等待副本确认收到。这意味着半同步复制最适合关闭服务器通过快速网络进行通信，对于远程服务器通过慢速网络进行通信最差。半同步复制通过将速度限制在哪些二进制日志事件可以从源发送到副本来影响性能。当用户太忙时，这会减慢它的速度，这在一些部署情况中是不希望的。

源与其副本之间的半同步复制操作方式如下：

副本指示它是否具有半同步功能，但以下情况它连接到源。
如果在源端启用了半同步复制并且至少有一个半同步副本，即线程在源块上执行交易提交，并且等待至少一个半同步副本确认它已收到交易的所有事件，或者直到发生超时。
副本确认接收事务事件只有在将事件写入其中继日志之后，并且刷新到磁盘。
如果发生超时而没有任何副本确认事务，源恢复为异步复制。当至少有一个半同步副本捕获时，源返回到半同步复制。
必须在源和副本上都启用半同步复制。如果禁用了源上的半同步复制，或者在源上启用但没有副本，则源使用异步复制。
当源阻塞时（等待来自副本的确认），它不会返回到执行交易。当阻塞结束时，源返回到会话，然后可以继续执行其他语句。此时，事务已在源端提交，并且至少有一人确认收到其事件。源必须确认的副本数在返回会话之前每笔交易的接收量为可配置的，并默认为一个确认。
在写入二进制日志时，当修改事务时发生的非事务表回滚将回滚。即使事务对后续事务没有影响，也会记录事务表的回滚，因为对非事务表无法回滚，必须发送到副本。
对于不在事务上下文中出现的语句（即当没有使用START TRANSACTION或SET autocommit=0启动任何事务时），自动提交已启用，每个语句隐式提交。通过半同步复制，源对这些语句进行阻塞，就像它对显式事务所做的那样。
默认情况下，源等待副本确认在将二进制日志同步到磁盘后收到事务，但在将事务提交到存储引擎之前。或者，您可以配置源以便源等待将事务提交到存储引擎，使用rpl_semi_sync_source_wait_point系统变量。此设置会影响复制特征和客户端可以在源上看到的数据。
您可以通过启用系统变量replication_sender_observe_commit_only来提高半同步复制的性能，这限制了回调并增加了共享锁并避免了不必要的锁获取。随着副本数量的增加，这些设置会有所帮助，因为争用锁可能会降低性能。半同步复制源服务器还可以从启用这些系统变量中获得性能优势，因为它们使用相同的锁定机制作为副本。

19.4.11 延迟复制

MySQL支持延迟复制，以便副本服务器故意在源之后执行事务至少指定的时间。本节介绍如何在副本上配置复制延迟，以及如何监视复制延迟。

默认复制延迟为0秒。使用CHANGE REPLICATION SOURCE TO SOURCE_DELAY=N语句将延迟设置为N秒。一个从源接收的事务在比提交晚至少N秒在直接来源上。每个事务都会发生延迟（不是事件，与以前的MySQL版本一样），实际延迟为仅强加于或。其他事件交易始终遵循这些事件，无需任何等待强加给他们的时间。

延迟复制可用于多种用途：防止用户在源上出现错误；测试系统在出现滞后时的行为方式；检查数据库过去的样子，没有必须重新加载备份。

复制延迟时间戳MySQL 8.4提供了一种新的延迟测量方法复制拓扑中（也称为复制滞后）这取决于以下与写入二进制日志。original_commit_timestamp：数量自写入事务时的纪元以来的微秒数（提交）到原始源的二进制日志。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 (2017-04-04 10:48:05.661130 WEST)

immediate_commit_timestamp=1491299285843771 (2017-04-04 10:48:05.843771 WEST)

/!80001 SET @@SESSION.original_commit_timestamp=1491299285661130//!/;
SET @@SESSION.GTID_NEXT= ‘aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa:1’/!/;

at 233

通常，是在所有副本上始终相同的。在源-副本复制中，事务的原始源的二进制日志始终与其相同。在副本的中继日志，事务的和与源的二进制日志相同；而在它自己的二进制日志，交易对应的当副本提交事务时。original_commit_timestamporiginal_commit_timestampimmediate_commit_timestamporiginal_commit_timestampimmediate_commit_timestampimmediate_commit_timestamp

在组复制设置中，当原始源是组的成员，当事务已准备就绪，可以提交。换句话说，当它完成了对原始源及其写入集的执行已准备好发送给组的所有成员认证。当原始源是外部服务器时组，是保存。特定事务的相同操作将复制到所有服务器组，以及正在复制的组外部的任何副本来自会员。交易的每个接收方还存储在其二进制日志中使用的本地提交时间。original_commit_timestamporiginal_commit_timestamporiginal_commit_timestampimmediate_commit_timestamp

查看组复制独有的更改事件，是一个特例。包含这些事件的交易是由每个组成员生成，但共享相同的GTID（因此，它们不是先在源中执行，然后复制到组，但组的所有成员都执行并应用相同的交易）。组成员为与视图更改事件关联的事务。

监视复制延迟监视复制延迟（滞后）的最常见方法之一依赖于SHOW REPLICA STATUS输出中的字段。然而，在使用复制拓扑时，此指标不适用比传统的源-副本设置更复杂，例如组复制。MySQL 8的添加提供了有关复制延迟的更精细程度的信息。这监视拓扑中复制延迟的推荐方法是使用以下性能架构表。Seconds_Behind_Masterimmediate_commit_timestamporiginal_commit_timestamp

replication_connection_status：与源连接的当前状态，提供有关上次和当前交易的信息连接线程排队到中继日志中。

replication_applier_status_by_coordinator：仅显示的协调器线程的当前状态使用多线程副本时的信息提供有关由协调器线程到工作线程的队列，以及它目前正在缓冲的事务。

replication_applier_status_by_worker：应用事务的线程的当前状态从源接收，提供有关由复制SQL线程或使用多线程副本时的每个工作线程。

使用这些表，您可以监视有关上次的信息事务处理的相应线程和线程当前正在处理的事务。这信息包括：交易的GTID事务的和，检索到从副本的中继日志original_commit_timestampimmediate_commit_timestamp线程开始处理事务的时间对于上次处理的事务，线程完成加工除了性能架构表之外，SHOW REPLICA STATUS的输出还有三个显示以下字段：SQL_Delay：非负整数指示使用CHANGE配置的复制延迟复制源到SOURCE_DELAY=N，其中N以秒为单位。SQL_Remaining_Delay：当是时，此字段包含一个整数指示延迟的剩余秒数。在其他次，此字段为。Replica_SQL_Running_StateWaiting until SOURCE_DELAY seconds after master executed eventNULLReplica_IO_StateState当复制SQL线程等待延迟时在执行事件之前经过，SHOW PROCESSLIST将其值显示为。StateWaiting until SOURCE_DELAY seconds after master executed event}}

吴代庄

关注

16
点赞
踩
9

收藏

觉得还不错? 一键收藏
打赏
0
评论
Mysql8.4参考手册走读（六）

若要使用复制作为备份解决方案，请从源到副本进行操作，然后备份副本。副本可以暂停和关闭，不影响源，因此您可以生成“实时”数据的有效快照，否则将需要源被关闭。备份数据库的方式取决于数据库的大小以及是否仅备份数据，或在发生故障时可以重建副本的备份数据和副本状态。因此，有两种选择：如果使用复制作为解决方案，使您能够备份源上的数据以及数据库的大小不是太大，mysqldump工具可能合适。请参见第19.4.1.1节“使用mysqldump备份副本”。
复制链接

扫一扫