下载掌阅APP，畅读海量书库
立即打开
本节将演示如何设置从一台服务器（主服务器）到另一台服务器（从服务器）的复制。这些步骤包括启用二进制日志、创建用于读取二进制日志的用户账户、准备从服务器、启动从服务器并测试复制功能。希望通过这些演示使读者能够完全掌握主从复制的原理及实施方法，并且能够对后面将介绍的InnoDB Cluster形成知识储备。
如果读者希望亲自体验这个演示过程，那么需要准备两台服务器——两台物理机或两台虚拟机。使用主从复制进行试验的最简单方法是，在测试环境里设置两台MySQL服务器。读者将看到如何在同一台主机上运行多个MySQL实例。作为前提条件，读者的操作系统上应该已经安装了MySQL服务器。如果没有安装MySQL服务器，请参考MySQL官网的在线手册，根据不同的操作系统进行安装。
配置主从复制有两种方法，通过二进制日志文件的名称、位置方式，以及使用GTID（全局事务标识符号）。这两种方法在配置的过程中稍微有些不同，本节将介绍这两种配置方法。
配置复制的主要步骤如下。
第一步，初始化数据目录。
第二步，配置主服务器。
第三步，配置从服务器。
第四步，启动MySQL实例。
第五步，创建复制用户账户。
第六步，将从服务器连接到主服务器。
第七步，启动复制。
第八步，验证复制状态。
注意，虽然本书中使用多个本地MySQL实例来演示如何使用复制，但在生产环境中设置复制的过程与其相同。读者只需按生产环境的实际情况来更改主机、驱动器、目录、端口等详细信息。演示中的各个步骤都运行在CentOS 7平台上。尽管有一些特定于平台的命令和选项，但该演示可以在macOS和Windows平台上运行，读者只需稍加更改即可。
用户需要为所使用的每台服务器的数据目录进行初始化。在本演示中，我们将在本地服务器上创建一个目录，用来包含所有数据。演示里将使用两个MySQL实例进行操作，用来代表一台主服务器和一台从服务器。下面演示如何创建所需的文件夹。请注意，如果在生产环境中设置复制，则需要考虑文件夹的使用权限，演示是在本地服务器上运行的，因此不需要额外的权限。
执行语句如下：
这样，我们就创建了路径<user_home>/rpl/data。现在，我们将进行数据文件夹的初始化，可以使用--initialize-insecure和--datadir选项。--initialize-insecure选项用于通知服务器初始化数据目录，服务器会直接略过用户验证等过程，生成数据目录，由于还没有创建任何用户，所以该过程不涉及安全风险。
--datadir选项用来指定数据目录的位置，在演示过程中，我们将指定两个不同的路径，用于分别存放两个MySQL实例的数据。执行语句如下：
在这里，我们还使用了--log-error选项，因为在进行初始化的过程中会生成随机密码，随机密码将会保存在错误日志里。错误日志的默认保存位置为/var/log/mysqld.log，为了便于管理，我们将错误日志的位置进行了更改。
然后，初始化MySQL服务器。执行语句如下：
同样，按照这种方式，读者可以在一台服务器上部署多个MySQL实例。需要注意的是，每一个MySQL实例需要使用唯一的server_id和不同的保存数据路径。接下来，我们就可以在配置文件中对相关变量进行配置。
首先，复制需要主服务器启用二进制日志记录。MySQL 8.0默认开启二进制日志，如果用户使用较旧版本的MySQL，则必须在配置文件中添加启用二进制日志的选项log_bin。用户需要为每个实例都准备一个配置文件。可以使用任意名称为配置文件命名，默认会使用my.cnf，Windows下的默认文件为my.ini。
用户在配置MySQL实例时，还需要为MySQL实例选择端口。在本演示中，主服务器使用3306端口，从服务器使用3307端口。此外，演示中将使用server_id=1来标识主服务器实例，使用server_id=2来标识从服务器实例。
除此之外，演示还需要一些其他设置，在这里不一一列出，我们仅关注一个主服务器的典型基本配置文件。下面显示了在本演示中用于主服务器的配置文件。
配置文件的内容如下：
在某些操作系统上，由于文件权限的原因，用户可能无法正常启动MySQL实例，需要检查相关的权限。
注意，配置文件有一个名为mysqld的部分，它只适用于MySQL服务器的执行。只有mysqld（MySQL服务器进程）和相关的可执行文件会读取这部分值。这些值包括datadir、basedir、port和socket（适用于*nix风格的操作系统）的常见设置。
然后，设置服务器ID（server_id=1），将复制信息以表的形式存储（master_info_repository=TABLE，复制在系统崩溃时可以恢复），开启二进制日志，并设置其保存路径和名称（log_bin=master_binlog）。
最后，将二进制日志配置为使用基于行格式（binlog_format=row），这是一种二进制日志格式，也是最新版本MySQL主从复制的默认格式。mysqlx部分的内容是与mysqlx协议相关的，这个协议支持文档存储（Document store），是MySQL 8.0的新功能，它需要使用默认为33060的端口号。
如果用户希望使用基于GTID的复制，则必须设置额外的选项。对主服务器来说，有三个选项：启用GTID、设置强制一致性，以及记录从服务器更新。启用GTID的主服务器的配置文件如下所示。注意，文件的第一部分与前面的示例相同，读者只需要添加最后几行来启用GTID。
配置文件的内容如下：
主从复制需要依靠二进制日志的传递来实现，因此，用户必须在主服务器上开启二进制日志，而从服务器上没有强制要求。考虑到从服务器的崩溃恢复，建议用户在从服务器上同样开启二进制日志。配置从服务器与主服务器相同，需要在从服务器上配置几个变量。
配置文件的内容如下：
注意，该配置文件里还设置了另外两个变量：report-port和report-host。设置这两个变量以确保执行相关语句时能够报告正确的信息，如SHOW SLAVE HOSTS。还需注意，这里将数据目录设置为从服务器的所在路径（datadir="/home/mysqlha/msrpl/data/slave"），并且更改了服务器的ID（server_id）。最后，还更改了二进制日志的名称（log_bin=slave_binlog），以确保用户可以知道日志来自哪台服务器。如果用户希望使用基于GTID的复制，可以添加与主服务器相同的一组变量。
配置文件的内容如下：
在本演示里，我们将使用GTID的复制，因此，我们需要创建一个名为slave.cnf的文件。如果用户希望添加更多从服务器，可以使用相同的方法创建额外的配置文件，只需更改数据目录、套接字、端口、服务器ID和二进制日志文件这几个位置。
配置文件准备完成后，我们就可以启动MySQL实例了，非常简单，只需要加上默认配置文件选项--defaults-file即可。
执行语句如下：
如果用户没有在配置文件的路径下运行命令，则需要给出配置文件的完整路径，通过使用“&”让其在一个后台进程运行。服务器启动后，用户可以查看终端/错误日志中的内容，以确认MySQL服务器是否正常启动。
终端输出的类似内容如下：
当用户看到“ready for connections.”出现时，意味着MySQL启动成功，输出信息里显示了几个警告，可以暂时不用处理，只要没出现错误，MySQL服务器就能够启动，如果出现了错误，或者无法启动，那么用户需要查看错误日志里面记载的内容，从第一个出现Error的地方开始查看，确定问题，解决问题后再次启动服务器。
主服务器启动成功之后，从服务器也应该能够正常启动，如果出现错误，很有可能是权限问题或者配置文件存在与主服务器冲突的设置，请仔细查看日志里面的提示。
在MySQL实例启动之后，用户必须在配置复制之前创建一个用户账户，用于让从服务器连接到主服务器，并能够读取二进制日志。这需要有一个特殊的权限REPLICATION SLAVE。请记住这里使用的用户名和密码，因为读者将需要用它来连接从服务器。
下面显示创建复制用户账户所需的语句。需要读者在所有服务器上执行这些语句。尽管从服务器不需要用户账户，但现在创建它将允许用户使用从服务器进行恢复、切换或故障转移，而不必再创建用户账户。事实上，该操作是允许自动故障转移所必需的执行步骤。
执行语句如下：
注意第一个和最后一个语句，这些语句通知服务器暂时禁用对二进制日志的更改。当我们不希望在复制拓扑中的其他服务器上复制语句时，就可以这样做。具体来说，不应该复制创建用户等一些维护和管理相关的语句。关闭二进制日志可以确保不会意外执行无法在其他机器上执行的事务。
执行这些语句的最佳方法是将它们保存到一个.sql文件中，然后通过mysql或mysqlsh客户端调用这个文件，执行内部保存的语句。在这里使用的文件名称为create_msrpl_user.sql。
文件的内容如下：
使用mysqlsh或者mysql客户端的source命令从文件中读取语句并执行它们。
使用mysqlsh客户端命令在所有实例上快速创建复制用户，执行语句如下：
使用mysql客户端命令在所有实例上快速创建复制用户，执行语句如下：
两种客户端使用的选项基本相同。--user或者-u后面要跟随数据库的用户名称，我们需要使用具有管理员权限的用户账户来创建复制用户账户，在这里使用了root、--host或者-h后面指定MySQL的主机地址，--port或者-P（大写）后面指定端口号，-e或--execute后面指定要执行的文件，mysqlsh比mysql多了一个--sql选项，因为mysqlsh可以使用三种模式运行脚本，因此我们需要指定使用SQL模式来执行。
在本书里，所有演示以使用mysqlsh为主，使用mysqlsh--user=root--host=localhost--port=3307--sql-e"source create_msrpl_user.sql"（注意端口号不同）对主从两台MySQL服务器配置复制用户账户。
准备就绪，接下来，我们可以将从服务器连接到主服务器并开始复制数据。
将从服务器连接到主服务器，首先要配置从服务器连接，然后启动复制。其具体过程，根据用户所使用的复制方法（一种方法是使用日志文件和位置进行连接，另一种方法是使用GTID进行连接）的不同而不同。
在使用日志文件和位置将从服务器连接到主服务器时，用户需要一些信息。这些信息是执行CHANGE MASTER语句所需的信息。CHANGE MASTER语句指示从服务器与主服务器建立连接，在使用该语句时我们需要主服务器的主机地址和端口号，二进制日志的日志名称、当前事件的位置、复制用户的名称和密码。这些信息的来源如表3-1所示。
表3-1
用户使用SHOW MASTER STATUS语句可以找到主服务器的二进制日志文件的相关信息。执行语句如下：
SOL语句的结尾使用\G会将表的内容垂直输出，方便用户查看。
通过执行上面的SQL语句，用户得到复制所需的全部信息，可以在从服务器上执行连接到主服务器的步骤。用户需要在每一台从服务器上都执行全部步骤，因此，我们可以把这些语句写入一个文件，通过mysqlsh执行。
文件的内容如下：
将上面内容保存在文件connect_master.sql中，通过mysqlsh执行。
执行语句如下：
在使用GTID将从服务器连接到主服务器时，用户同样需要一些执行CHANGE MASTER语句所需的信息。表3-2显示了所需信息的完整列表。该表包括一个可以找到信息的来源、示例及本演示中使用的主服务的相关信息。
表3-2
用户可以发现，基于GTID的复制比基于二进制日志文件位置的复制少了一些信息，这些信息正是关于日志名称和位置的。也就是说，基于GTID的复制将不会使用日志名称和位置信息。GTID握手过程将解析这些信息。用户所需要的只是主机连接信息、复制用户和密码。对于启用GTID的复制，用户使用一个特殊参数MASTER_AUTO_POSITION来指示与复制自动协调相关的连接信息。
执行语句如下：
同样，用户必须在每台从服务器上执行CHANGE MASTER语句，将这些语句保存在文件change_master_gtid.sql中，然后用mysqlsh执行。
执行语句如下：
现在，我们已经配置好复制，下一步，通知服务器开启连接并启动复制。
注意，读者选择一种复制方式进行配置即可，不要同时开启两种复制方式。
用户需要启动从服务器进程。语句非常简单：START SLAVE。我们将在所有的从服务器上运行该语句。
执行语句如下：
当用户执行START SLAVE时，通常不会报告任何错误，因此，用户需要确认复制是否正常启动。可以执行SHOW SLAVE STATUS；语句来确认复制的状态。
执行语句如下：
用户需要仔细检查从服务器的状态，需要关注几个字段的信息，如果发现错误，需要及时修复。例如，第一行（Slave_IO_State）显示了从服务器I/O线程状态的文本消息。I/O线程用于从主服务器的二进制日志中读取事件。此外，还有一个SQL线程用于从中继日志中读取事件并执行它们。
用户需要确保I/O线程和SQL线程都在运行，并且没有错误。但是在这个演示里面，读者会发现Slave_IO_Running的值是Connecting，并不是YES，并且在其下面发现了错误信息。
原因是MySQL 8.0默认使用了新的认证插件caching_sha2_password，使用该插件时，要求使用安全连接，因此演示中报告连接失败。解决该问题有两种方法：一种方法是将认证方式改回8.0版本之前的默认方式，另外一种方法需要用户开启安全连接。推荐使用后一种方法，因为8.0版本改变认证方式的目的是提升安全性，如果仍使用旧的认证方式，那么用户将无法利用更安全的认证方法。
开启MySQL的安全连接需要使用SSL（Secure Socket Layer，安全套接字协议）证书和密钥文件，用户首先需要创建证书和密钥文件，MySQL提供了创建SSL证书和密钥的方法。此外，MySQL还支持使用OpenSSL创建证书和密钥。本演示使用MySQL提供的创建方法，希望使用OpenSSL创建证书和密钥的用户可以参考MySQL的官网手册。
MySQL提供了两种方式来创建SSL证书和密钥文件，一是服务器可以在启动时为MySQL自动生成这些文件，二是用户可以手动调用mysql_ssl_rsa_setup实用程序生成这些文件。
MySQL通过auto_generate_certs、sha256_password_auto_generate_rsa_keys和caching_sha2_password_auto_generate_rsa_keys系统变量控制自动生成这些文件。这些变量在默认情况下是开启的。它们可以在服务器启动时启用和检查，不能在运行时进行设置。
如果我们在系统启动时开启auto_generate_certs变量，MySQL服务器就会在数据目录下面进行检查，如果发现缺失相关文件，将会自动创建。对这个演示而言，MySQL已经在数据路径下面创建了相关的文件。
执行语句如下：
MySQL默认生成的文件名为ca.pem、server-cert.pem和server-key.pem，它们对应的系统变量为ssl_ca、ssl_cert和ssl_key。因此，我们将直接利用这些文件配置演示的复制。在这里需要更改主服务器的配置文件，在进行此操作之前，用户需要在从服务器上停止复制。
执行语句如下：
用户需要更改master.cnf配置文件，在[mysqld]部分添加如下内容：
建议使用完整的路径。
主服务器上的master.cnf文件的内容最终如下：
修改配置文件后，需要重新启动服务器。
首先，停止MySQL服务器，执行语句如下：
然后，重新启动MySQL，执行语句如下：
接下来，用户需要在从服务器上进行操作。执行操作时，用户可以修改从服务器的配置文件slave.cnf，也可以选择在CHANGE MASTER语句里面添加相关信息。
修改从服务器的配置文件与修改主服务器的配置文件相似。需要在从服务器配置文件中的[client]下面添加以下内容。
● ssl_ca ：CA（Certificate Authority）证书文件的路径名。
● ssl_cert ：客户端公共密钥证书文件的路径名。
● ssl_key ：客户端私钥文件的路径名。
修改后的slave.cnf文件内容如下：
修改配置文件后，对服务器进行重启。
首先停止MySQL服务器，执行语句如下：
然后，重新启动MySQL服务器，执行语句如下：
注意，在这里使用了--skip-slave-start选项，因为我们还需要修改CHANGE MASTER语句，所以需要在服务器启动时略过启动复制的过程。
下面，我们更改CHANGE MASTER语句，向其添加MASTER_SSL=1，其功能是表明主服务器开启安全连接。同样，我们可以把它保存在脚本文件内，然后执行该文件。
执行语句如下：
执行后，再次启动复制，并检查复制状态，查看是否有错误发生。
执行语句如下：
到目前为止，没有报告错误信息，一切正常。这时，我们可以在主服务器里创建一个数据库（模式），并向里面添加一些数据，查看这些数据是否能够正常进行复制。
用户可以从MySQL官网下载一些测试数据，在演示里，我们使用下载的sakila数据库，其中包括建表语句和数据。
执行语句如下：
数据导入后，用户可以进行验证，在主服务器上使用mysqlsh客户端登录MySQL服务器，并执行如下语句：
在从服务器上同样执行show语句：
读者可以看到sakila数据库已经在主/从数据库中分别出现，这时，我们再来验证表里面的记录是否已经复制。
在主服务器上执行语句如下：
在从服务器上执行语句如下：
结果一致，说明搭建的复制已经成功。
GTID（Global Transaction ID）为全局事务提供了唯一标识，使用GTID时，每个事务都可以在主服务器和从服务器上进行标识和跟踪。这意味着在配置新的从服务器或将故障转移到新的服务器时，不必使用日志文件或这些文件中的位置，从而极大地简化这些工作。基于GTID的复制完全基于事务，因此，用户可以很容易地确定主从服务器是否一致。只要在主服务器上提交的所有事务能够在从服务器上提交，就可以保证两者之间的一致性。
在现实中，仍然有许多旧的系统使用基于日志位置方式的复制，本节将演示如何将使用日志位置方式的复制转换为使用GTID的复制。
在开始演示之前，读者需要详细了解GTID。GTID是事务的唯一标识符，与MySQL服务器上提交的每个事务相关联。GTID的格式为GTID=source_id：transaction_id，source_id为原始服务器的UUID，transaction_id为从1开始连续增长的事务ID。例如，主服务器的UUID是5CFDDB42-3D81-59D0-B8E1-87339B2B4727，在这台服务器上执行的第20个事务的GTID为5CFDDB42-3D81-59D0-B8E1-87339B2B4727:20。自增事务ID的上限为264-1，即9，223，372，036，854，775，807。当事务ID超过该值时，MySQL会发生由二进制日志错误产生的行为（系统变量binlog_error_action指定的行为），默认为ABORT_SERVER，服务器在遇到二进制日志中的此类错误时会暂停日志记录并关闭服务器。GTID存储在一个名为gtid_executed的表里面，这个表保存在MySQL的系统数据库mysql里。
使用GTID进行复制时，MySQL将按照如下过程进行。
（1）事务在主服务器上执行并提交。服务器为该事务分配一个GTID。如果没有将事务写入二进制日志（例如，事务为只读），则不会为其分配GTID。
（2）如果事务分配了GTID，那么在提交时，GTID将在事务开始时写入二进制日志中，并且GTID将添加到系统变量＠＠GLOBAL.gtid_executed中的GTID集合上。GTID集合包含全部已提交的GTID事务，并且在复制中用于表示服务器状态。启用二进制日志记录后，gtid_executed系统变量中的GTID集合是已经进行应用事务的完整记录。注意，mysql.gtid_executed表中的记录此时不完整，因为最新历史记录仍保存在当前的二进制日志文件中，当进行二进制日志轮换时，才会将日志中保存的记录写入mysql.gtid_executed表。
（3）将二进制日志数据传输到从服务器上，并存储在从服务器的中继日志中，从服务器将读取GTID，并设置其系统变量gtid_next的值。从服务器使用该GTID记录下一个事务。
（4）在处理事务时，从服务器验证是否有线程拥有gtid_next中保存的GTID。首先，需要读取并检查复制的事务的GTID，在处理事务本身之前，从服务器不仅保证已应用的事务中不存在该GTID，还需确保其他会话未读取此GTID，并且未提交关联的事务。如果多个客户端同时试图对同一个事务进行应用，服务器将仅允许其中一个执行。系统变量（＠＠GLOBAL.gtid_owned）显示从服务器中当前使用的每个GTID及拥有它的线程的ID。如果已经使用了GTID，则不会引发任何错误，会忽略这个事务。
（5）如果尚未使用GTID，则从服务器将应用复制的事务。因为gtid_next已经被设置为主服务器分配的GTID，所以从服务器不会生成新的GTID，而是使用gtid_next中存储的GTID。
（6）如果在从服务器上启用了二进制日志记录，则在事务开始时将GTID写入二进制日志中，将GTID作为gtid_log_event保存。当二进制日志轮换或关闭服务器时，服务器都会将前一个二进制日志文件的所有事务的GTID写入mysql.gtid_executed表中。
（7）如果在从服务器数据库上禁用了二进制日志记录，则GTID将直接写入mysql.gtid_executed表中，可以自动保留GTID。从MySQL 8.0开始，DDL语句和DML语句都具有原子性。因此，mysql.gtid_executed表保存了从服务器应用的事务的完整记录。
（8）将复制事务提交到从服务器后，GTID将被添加到从服务器的系统变量（＠＠GLOBAL.gtid_executed）中的GTID集。
MySQL复制支持从使用日志文件和位置的方法转换为使用GTID的复制，在进行复制模式转换时，用户首先要开启GTID模式。可以执行show variables like'GTID%'；来查看当前GTID的设置。
执行语句如下：
我们可以在线开启GTID模式，变量gtid_mode用来开启GTID，它有四个可选值：
● OFF ：不产生GTID，从服务器只接受不带GTID的事务。
● OFF_PERMISSIVE ：不产生GTID，从服务器接受全部的事务。
● ON_PERMISSIVE ：产生GTID，从服务器接受全部的事务。
● ON ：产生GTID，从服务器只接受带GTID的事务。
对gtid_mode的值进行切换时，用户只能按照上面的顺序一次切换一个值，假设现在的值为OFF_PERMISSIVE，用户只能将其切换到OFF或者ON_PERMISSIVE，而不能直接将其设为ON。因此，我们将按照下面的步骤进行：
首先，在从服务器上执行STOP SLAVE语句。
执行语句如下：
注意，在将gtid_mode设置为ON之前，要开启强制一致性，否则会出现如下的错误信息：
开启强制一致性的执行语句如下：
现在我们已经在主服务器上开启了GTID，为了能够在服务器下一次启动时自动开启GTID，用户可以把这部分内容写入my.cnf配置文件中。
同样的操作，在从服务器上开启GTID。
执行语句如下：
在执行CHANGE MASTER之前，用户可以查看从服务器上是否有GTID的脏数据，执行select*from mysql.gtid_executed；语句和show variables like'gtid_purged'；语句确认是否存在数据，如果存在数据，则说明从服务器上有GTID的脏数据，可以在从服务器上执行reset master；语句，之后执行CHANGE MASTER语句。
执行语句如下：
然后，执行START SLAVE语句，并检查从服务器状态。
执行语句如下：
以上内容是关于如何配置复制的一个简单的演示，读者可以选择使用任意方法搭建复制，但极力推荐使用GTID。GTID可以为MySQL的运维管理提供极大的便利性，比如，后面要介绍的InnoDB Cluster，它要求在使用时必须开启GTID。
复制有两种类型：异步复制和半同步复制。异步复制是MySQL默认使用的复制类型，在异步复制的情况下，主服务器产生二进制日志更改后，直接将日志内容发送给从服务器，并提交存储引擎。在极端情况下，当日志发送后，由于网络异常等原因，从服务器未接收日志，与此同时，主服务器发生不可恢复的故障，造成这部分传输数据丢失。为了避免这种情况，MySQL推出了半同步复制功能，能够避免数据丢失，实现RPO=0。
读者可能会有疑问，为什么不使用完全同步复制呢？如果使用完全同步复制，则主服务器需要等待全部从服务器接收日志，并提交到存储引擎，会产生很大的延迟。半同步复制的开销介于异步复制与完全同步复制之间，主服务器等到从服务器收到日志的应答之后，将事务提交到存储引擎。因此，半同步复制能够保证，即使在主服务器崩溃后，已经提交的事务也能够通过日志传输到从服务器。相比较于异步复制，半同步复制能够保证数据的完整性；相比较于全同步复制，半同步复制延迟低、速度快。
MySQL的半同步复制功能通过插件来实现。在使用半同步复制的主从服务器上一定要安装并启用半同步复制插件，如果主从服务器没有同时开启半同步复制功能，则执行异步复制。半同步复制在执行过程中会遵照下面的步骤进行。
第一步，检查是否启用半同步。
第二步，如果已启用半同步插件，则在主服务器上进行的提交将等待从服务器的应答或发生超时。
第三步，当发生超时后，半同步复制将恢复为异步复制，直至有一台从服务器赶上主服务器的执行进度，异步复制将返回半同步复制。
在MySQL的安装包中，已经包含了半同步复制插件，在默认情况下，并没有启用该插件，用户需要分别在主从服务器上启用半同步插件。
（1）在主服务器上安装半同步插件。
执行语句如下：
主服务器上的半同步插件名称为rpl_semi_sync_master，它对应的文件名称为semisync_master.so，如果是Windows系统，文件名的后缀为.ddl。在默认情况下，插件的.so文件保存在/mysql/lib/plugin下面。
（2）在从服务器上安装半同步插件。
执行语句如下：
从服务器上插件的名称为rpl_semi_sync_slave，它对应的文件名为semisync_slave.so，与主服务器一样，插件保存在/mysql/lib/plugin下面。
插件安装完成之后，用户可以在INFORMATION_SCHEMA.PLUGINS里面查看是否已经正确安装。
执行语句如下：
结果显示为ACTIVE，表示MySQL服务器已经正确安装了插件。
下面，需要分别在主从服务器上开启半同步复制。
（1）在主服务器上开启半同步复制。
执行语句如下：
在从服务器上停止I/O线程。
执行语句如下：
注意，由于演示环境是在一台已经运行异步复制的服务器上开启半同步复制，在启用半同步复制之前，需要先停止I/O线程，启用半同步复制后，再开启I/O线程。因此，我们需要执行STOP SLAVE IO_THREAD语句。另外，由于这里使用的MySQL是8.0.23版本，主从复制的术语已经从Master/Slave改为Source/Replica，因此会有警告信息，提示用户该术语已经降级，将来会删除。
（2）在从服务器上开启半同步复制。
执行语句如下：
至此，半同步复制的搭建结束，如何能够确认MySQL是否已经启用了半同步复制呢？
读者可以通过在主服务器执行SQL语句来查看变量值，以确认半同步复制是否启用。
执行语句如下：
读者可以看到，主服务器已经开启了半同步复制，超时设置为10000ms，等待从服务器应答数量为1，应答的时间点为AFTER_SYNC。
在从服务器上执行SQL语句查看复制相关的变量值，确认是否启用。
执行语句如下：
通过变量值，读者可以看到从服务器已经开启了半同步复制。
如果用户希望获取当前的复制状态，则可以在主服务器上执行SHOW STATUS语句。
执行语句如下：
Rpl_semi_sync_master_clients显示当前有多少个从服务器；Rpl_semi_sync_master_yes_tx显示当前已经成功接收多少个应答；Rpl_semi_sync_master_no_tx显示当前有多少个失败应答。
在从服务器上执行SHOW STATUS语句，确认复制状态。
执行语句如下：
Rpl_semi_sync_slave_status表示当前半同步复制是否运行。
注意，用户在使用半同步复制的过程中，需要对复制进行监控，以防止由于超时等原因恢复为异步复制，以及在极端情况下造成数据丢失。