This is a read-only copy of the MariaDB Knowledgebase generated on 2024-05-11. For the latest, interactive version please visit https://mariadb.com/kb/.

Replication Threads

The terms master and slave have historically been used in replication, and MariaDB has begun the process of adding primary and replica synonyms. The old terms will continue to be used to maintain backward compatibility - see MDEV-18777 to follow progress on this effort.

MariaDB的复制实现需要几种类型的线程。

主服务器上的线程

主服务器通常只有一种与复制相关的线程:二进制日志转储线程。

如果启用了半同步复制,则主服务器还具有ACK接收器线程。

二进制日志转储线程

二进制日志转储线程在主服务器上运行,并将binary log 转储到副本。可以通过运行SHOW PROCESSLIST语句并查找thread command“Binlog Dump”的线程来识别此线程。

主服务器为连接到主服务器的每个副本创建一个单独的二进制日志转储线程。可以通过执行SHOW SLAVE HOSTS语句来确定连接到主服务器的副本。

二进制日志转储线程和关闭过程

当主服务器关闭并经过正常关闭过程时,主服务器以随机顺序终止客户端线程。默认情况下,主服务器也认为其二进制日志转储线程是常规客户端线程。因此,在客户端线程仍然存在时可以终止二进制日志转储线程,这意味着在正常关闭期间可以在主服务器上写入不会被复制的数据。即使使用半同步复制也是如此。

MariaDB 10.4及更高版本中,可以通过使用mariadb-admin实用程序或SHUTDOWN命令关闭服务器并提供特殊选项来解决此问题。

例如,可以通过使用mariadb-admin实用程序并提供--wait-for-all-slaves选项以及使用实用程序执行shutdown命令来解决此问题:

mariadb-admin --wait-for-all-slaves shutdown

或者可以通过使用SHUTDOWN命令关闭服务器并向命令提供WAIT FOR ALL SLAVES选项来解决此问题:

SHUTDOWN WAIT FOR ALL SLAVES;

当提供这些特殊选项之一时,服务器仅在所有客户端线程被杀死后才杀死其二进制日志转储线程,并且仅在最后一个binary log已发送到所有连接的副本后才完成关机。

MariaDB 10.4及更高版本中,仍无法默认启用此行为。这意味着,在使用systemdsysVinit等工具关闭服务器时,当前无法访问此行为。

MariaDB 10.3及之前版本中,建议在关闭旧的主服务器之前手动将副本切换到新的主服务器。

ACK接收器线程

当启用半同步复制时,半同步副本会向其主服务器发送确认(ACK)以确认它们已接收某个事务。主服务器创建ACK接收器线程以接收这些ACK。

副本上的线程

副本有三种与复制相关的线程:副本I/O线程,副本SQL线程和工作线程,这些线程仅在使用parallel replication时适用。

当使用multi-source replication时,每个独立的复制连接都有其自己的每种类型的副本线程。

副本I/O线程

副本的I/O线程从主服务器接收binary log事件并将其写入其relay log

二进制日志位置

可以通过执行SHOW SLAVE STATUS语句来检查副本I / O线程的binary log位置。它将显示为 Master_Log_File Read_Master_Log_Pos 列。

可以通过使用CHANGE MASTER语句设置副本I / O线程的binary log位置,并设置MASTER_LOG_FILEMASTER_LOG_POS选项。

副本I/O线程的binary log位置和大多数其他CHANGE MASTER选项的值都写入默认的 master.info 文件或由master_info_file选项配置的文件中。当MASTER_USE_GTID选项设置为 NO时,副本I / O线程会在下载事件时保持此binary log位置更新。否则,该文件不会按事件更新。有关更多信息,请参见CHANGE MASTER TO:Option Persistence

以下是翻译的文本:

副本SQL线程

副本SQL线程从relay log中读取事件。它对它们的处理取决于是否使用parallel replication。如果未使用parallel replication,则SQL线程将事件应用于其本地数据的副本。如果使用parallel replication,则SQL线程将事件移交给其工作线程以并行应用。

Relay Log Position

可以通过执行SHOW SLAVE STATUS语句来检查副本SQL线程的relay log位置。它将显示为Relay_Log_FileRelay_Log_Pos列。

可以通过使用CHANGE MASTER语句设置副本SQL线程的relay log位置,方法是设置RELAY_LOG_FILERELAY_LOG_POS选项。

副本SQL线程的relay log位置写入默认的relay-log.info文件或由relay_log_info_file系统变量配置的文件中。副本SQL线程在应用事件时会保持此relay log位置更新。有关更多信息,请参见CHANGE MASTER TO:选项持久性

Binary Log Position

可以通过执行SHOW SLAVE STATUS语句来检查副本SQL线程的当前relay log位置的相应binary log位置。它将显示为Relay_Master_Log_FileExec_Master_Log_Pos列。

GTID位置

如果副本正在复制包含GTIDbinary log事件,则副本SQL线程将每个应用于mysql.gtid_slave_pos表中的GTID写入。可以通过gtid_slave_pos系统变量检查和修改此GTID。

如果副本启用了log_slave_updates系统变量,并且如果副本启用了binary log,则由副本SQL线程写入的每个写入也将进入副本的binary log。这意味着,复制事务的GTIDs将反映在gtid_binlog_pos系统变量的值中。

有关更多信息,请参见CHANGE MASTER TO:GTID Persistence

工作者线程

当使用parallel replication时,SQL线程将事件移交给其工作线程以并行应用。

Content reproduced on this site is the property of its respective owners, and this content is not reviewed in advance by MariaDB. The views, information and opinions expressed by this content do not necessarily represent those of MariaDB or any other party.