MySQL 8 复制

MySQL 8.0 支持的复制方法：

传统方法（基于二进制日志文件位置）

新方法（基于GTID）

MySQL 8.0 支持的同步类型：

异步复制（内置）

同步复制（NDB集群）

半同步复制（半同步复制插件）

延迟复制（CHANGE MASTER TO语句的MASTER_DELAY选项）

MySQL 8.0 支持的复制格式类型：

基于语句的复制（binlog_format=statement）

基于行的复制（binlog_format=row）

基于混合模式的复制（binlog_format=mixed）

设置基于二进制日志文件位置的复制

设置中需要考虑的常见地方：

Master端，启用二进制日志、设置一个唯一的Server ID。

Slave端，设置一个唯一的Server ID。

注：如果Slave是从Master克隆的，比如虚拟机，注意删除Slave端数据目录下的auto.cnf文件。该文件记录了Server UUID，在复制环境中，Server UUID也需要唯一。在MySQL Server启动后，会重新生成该文件。

可选的，为Slave创建一个单独用户用于读取Master二进制日志。

在创建快照或者启动复制前，需要记录Master端当前的二进制日志文件位置。这个位置是作为复制起始点的。可以通过mysqldump工具提供的--master-data选项在备份Master数据时，记录备份开始时二进制日志坐标位置。在备份数据时还需要考虑存储数据所使用的存储引擎，对于非事务存储引擎，比如MyISAM，需要在Master端获取一个读锁（比如：flush tables with read lock；）来停止处理语句，拷贝数据，读取二进制日志坐标位置。对支持事务的存储引擎，比如InnoDB，不需要获取读锁，可以通过多版本读一致性，mysqldump工具提供的--single-transaction选项实现。这里需要事务足够长，能够传输快照（可能存在类似Oracle中快照过久的问题）。

配置Slave端连接信息。

实现Master和Slave之间的安全复制。

下面是具体实现：

配置Master端

在MySQL 8.0版本，二进制日志默认启动，通过下面命令验证：

mysql> select @@log_bin;

可以位置二进制日志指定非默认base name，这是也推荐的。在my.cnf选项文件中添加如下信息：

log_bin='/usr/local/mysql-5.7.28-linux-glibc2.12-x86_64/log/binlog'

设置MySQL Server ID,在my.cnf选项文件中添加如下信息：

server_id=140

注：Server ID需要在复制环境中唯一，用来唯一标识Server。在MySQL 8.0 中，Server ID默认值是1，之前的版本这个值是需要显式设置的，否则二进制日志不能启用。Server ID的值不能设置为 0，在Master端如果该值为 0，会导致Slave不能连接到该Master；如果Slave端Server ID设置为 0，会导致Slave拒绝连接到Master端。这里用IP地址的最后一位来作为Server ID。

下面这些是可选的系统变量设置：

innodb_flush_log_at_trx_commit=1

sync_binlog=1

注：这两个系统变量用于保证最大的持久性和一致性。

skip_networking 系统变量不能启用，否则会导致Slave无法连接到Master。

配置Slave端

在Slave端需要配置Server ID，在整个复制拓扑中唯一，比如：

server_id=150

注：MySQL 8.0 中由于默认启用了二进制日志，该日志在Slave端不是必须的，如果不需要，可以通过如下方式禁用：

skip_log_bin=1
log_slave_updates=0

在Slave端启用二进制日志的好处：Slave可以做备份和崩溃恢复，以及在级联复制中，即作为slave也作为master。

Slave端的中继日志默认使用的是主机名作为base name，可以通过下面系统变量调整设置：

relay_log='/usr/local/mysql/log/relay-bin'

slave_load_tmpdir 系统变量：如果tmpdir 系统变量指定的是一个系统重启后会清除的目录，可以将slave_load_tmpdir 指定到一个永久目录。根据Master端可能的LOAD DATA情况，确定永久目录的空间大小。

为复制创建用户

mysql> create user 'repl'@'192.168.1.%' identified by 'oracle';

mysql> grant replication slave on *.* to 'repl'@'192.168.1.%';

注：在MySQL 8.0中，默认是caching_sha2_password 插件做用户认证。通过该用户连接到Master有两种方式：使用加密连接或者RSA密钥。

获取Master二进制日志坐标

情况一：如果计划停掉Master来做数据快照，获取二进制日志索引文件即可获取二进制日志坐标，因为下次Master Server启动后会生成一个新的二进制日志文件。

情况二：如果是新的Master和Slave环境，可以通过下面方式获取Master二进制日志坐标：

mysql> show master status;

情况三：如果Master是包含数据正在运行的环境，可以通过下面方式获取二进制日志坐标：

mysql> flush tables with read lock;

注：该语句会阻塞用户的写操作。同时注意在完成后续操作前，不要退出运行该语句的会话，否则READ LOCK会被释放。

mysql> show master status;

情况四：如果之前Master没有启用二进制日志，那么二进制日志坐标是 ' ' 和 4。

选择方法做数据快照

方法1：使用mysqldump工具做数据快照，这对于使用InnoDB存储引擎存储数据的Master更加合适。比如：

mysqldump -uroot -poracle --all-databases --master-data > dbdump.db

注：mysqldump 选项说明：

--master-data：使用这个参数会在DUMP文件中生成备份开始时的二进制日志坐标位置，这个位置信息在做时间点恢复或者配置复制时使用。这个选项也会自动添加一个全局读锁，在备份完成后自动释放读锁。因此，如果使用该选项，前面的FLUSH TABLES WITH READ LOCK语句则不需要了。一般与--single-transaction配合使用，仅在开始时添加读锁。

--single-transaction：在单个事务中对所有表做一致性快照。仅对支持多版本的存储引擎保证DUMP文件一致性，目前只有InnoDB。为保证有效的DUMP文件，在备份过程中，需要没有其他的ALTER TABLE, DROP TABLE, RENAME TABLE,TRUNCATE TABLE操作。

--set-gtid-purged：如果Master和Slave开启了GTID，DUMP文件默认包含GTID信息，可以通过该参数调整。

方法2：使用裸数据文件创建数据快照

设置复制Slave

步骤1：

情况一：如果Master和Slave都是新的，可以启动Slave并执行CHANGE MASTER TO语句。

情况二：如果新的Master数据来源于其他数据库，可以先配置好主从复制，在将数据导入到Master，这样数据会自动复制到Slave端。比如：

shell> mysql -h master < fulldb.dump

情况三：如果需要导入Master的快照数据，可以根据产生数据快照的方法进行数据导入，比如：

使用mysqldump工具导入数据：

shell> mysql < fulldb.dump

使用裸数据文件创建的快照，可以通过下面方式提取数据文件到数据目录：

shell> tar xvf dbdump.tar

步骤2：

使用 --skip-slave-start 选项启动Slave Server，这样复制在启动时不会开始。如果Slave端没有配置到Master端的复制连接信息，这个选项可以不添加。

步骤3：

配置Slave到Master连接，比如：

CHANGE MASTER TO

MASTER_LOG_FILE='binlog.000001',

MASTER_LOG_POS=155,

MASTER_USER='repl',

MASTER_PASSWORD='oracle',

MASTER_HOST='192.168.1.140',

MASTER_SSL=1;

步骤4：

启动Slave 线程：

mysql> start slave;

补充：

查看复制连接信息，可以通过下面命令，比如：

mysql> show slave status\G

Slave提供了两个状态日志用于跟踪复制进度，存储复制配置信息：

MySQL 8.0 中默认使用mysql.slave_master_info、mysql.slave_relay_log_info表。在之前的版本中，master_info_repository、relay_log_info_repository配置使用table或者file存储信息。

在执行上面的CHANGE MASTER TO 语句时有两个WARNINGS,解决方法如下：

通过SSL连接到Slave后，执行下面的命令：

CHANGE MASTER TO

MASTER_LOG_FILE='binlog.000001',

MASTER_LOG_POS=155,

MASTER_HOST='192.168.1.140',

MASTER_SSL=1;

START SLAVE USER='repl' PASSWORD='oracle';

在复制环境中添加Slave

情况一：

如果是类似虚拟化的环境，可以通过克隆现有的Slave，删除数据目录下的auto.cnf文件即可，配置一个唯一的Server ID即可。

情况二：

步骤1、停止现有的Slave复制，记录Slave状态信息，尤其是Master二进制日志文件和中继日志文件位置，比如：

mysql> STOP SLAVE;

mysql> SHOW SLAVE STATUS\G

步骤2、停掉Slave Server，比如：

shell> mysqladmin shutdown

步骤3、拷贝数据目录，包括日志文件和中继日志文件。

在拷贝前，确认与现有的Slave相关文件实际存储在数据目录下。Innodb system tablesapce、undo tablespace、log file、file-per-table tablespace 可能存储在定义的位置。

如果master info 和 relay log info repositories  存储在file中，也需要拷贝到新的Slave中。

拷贝后，删除数据目录下的auto.cnf，修改my.cnf配置文件中的server_id。

使用GTID复制

当使用GTID，标识和跟踪事务当它提交时。

GTID区别客户端事务和复制事务。如果客户端事务没有写到二进制日志（过滤，或者只读事务），不会为其分配GTID。

mysql.gtid_executed表

在MySQL 8.0.17版本之后，对于InnoDB存储引擎，事务提交之后相关GTID会立即写入mysql.gtid_executed表中。这带来了一些好处，比如：

在MySQL 8.0.17之前，如果mysql.gtid_executed表不能写入，二进制日志需要轮询，如果轮询原因不是因为max-binlog-size，Server会产生一个warning。如果是因为max-binlog-size，Server会根据binlog_error_action参数的定义处理。

关于mysql.gtid_executed表的压缩：

如果二进制日志没有启用，gtid_executed_compression_period 参数控制执行了多少个事务之后开始压缩表。

启用了二进制日志之后，mysql.gtid_executed表压缩在二进制日志轮询中执行。

MySQL 8.0中关于GTID的一些做法：

如果二进制日志在Slave Server上禁用，在事务提交后，MySQL会追加一条语句将GTID信息写入mysql.gtid_executed表中，对于DDL语句或者DML语句都实现了原子性。在之前的版本中，只有DML操作是原子的。

在MySQL 8.0.17 之后，即使开启了二进制日志，对于InnoDB存储引擎，在事务提交后，也会将GTID信息写入到mysql.gtid_executed中。而不会像之前的版本在二进制日志轮询时，才会将二进制日志中的GTID信息写入到mysql.gtid_executed。这样对于只是用了InnoDB存储引擎的数据库来说，mysql.gtid_executed表也是保存了Server上提交的所有事务的GTID信息。

在MySQL 8.0 中，有一个操作目前还不是原子性的：在事务提交后，将GTID信息写入到全局系统变量GTID_EXECUTED.在一般情形下，GTID_EXECUTED全局系统变量表示Server 上的所有已提交事务的GTID信息。

关于事务过滤：

在Master端，过滤的客户端事务不会写到GTID_EXECUTED系统变量中，也不会写到mysql.gtid_executed表中。

在Slave端，过滤的复制事务，如果二进制日志开启，会在日志中添加一个空事务，在空事务前添加GTID信息。如果二进制日志没有开启，在Slave Serve上过滤的复制过来的事务也会写到GTID_EXECUTED系统变量及mysql.gtid_executed表中。

这样做的目的：保证GTID_EXECUTED系统变量和mysql.gtid_executed表的GTID连续性，更好的压缩；同时利用GTID的自动跳过功能，防止已复制事务再次复制应用。

关于Slave Server多线程复制：

Slave Server端配置系统变量slave_parallel_workers，该变量指定复制时的并发线程数。一般会与slave_parallel_type系统变量配合使用。对于Master端有大量并发事务的情况下，通过并发应用Master Server组提交（Group Commit）事务可以提高复制应用效率。

在使用slave_parallel_workers > 0，如果没有指定slave_preserve_commit_order=1，可能会导致GTID_EXECUTED系统变量中的GTID出现GAPS。在Master端以及单线程复制Slave端，GTID_EXECUTED单调递增不会出现GAPS问题。

在多线程Salve Server，GAPS仅发生在最近应用的事务，如果Slave Server正常停止，比如：STOP SLAVE，正在执行的事务会应用，这样GAPS会被填充。但是如果是Server故障，或者使用KILL语句停止复制，GAPS可能会被保留。

GTID Auto-Positioning

当Master 和 Slave 都启用了GTID模式（gtid_mode=on），Slave连接配置指定了MASTER_AUTO_POSITION，Slave配置中就不再需要指定Master 二进制日志偏移（MASTER_LOG_FILE、MASTER_LOG_POS）。

流程：

在初次握手时，Slave Server发送已经接收或者提交的GTID SET。比如，

通过 select @@global.gtid_executed; 查看已提交的事务GTID SET。

通过 SELECT RECEIVED_TRANSACTION_SET FROM PERFORMANCE_SCHEMA.replication_connection_status; 查看已接收的GTID SET。

注：如果Slave Server包含多个来源的GTID，通过Server UUID区分不同的来源。

Master根据从Slave 接收到的GTID SET，从二进制日志中发送Slave Server没有的GTID SET。

在这个过程可能存在的问题:

应该发送给Slave的事务从Master的二进制日志文件中删除了,或者说事务的GTID被添加到GTID_PURGED中.在这种情况下,Master发送错误信息:ER_MASTER_HAS_PURGED_REQUIRED_GTIDS 给Slave,同时在Master 错误日志中记录一个WARNING:ER_MASTER_HAS_PURGED_REQUIRED_GTIDS.

修正:

根据ER_FOUND_MISSING_GTIDS 信息,考虑从其他源端复制事务到Slave端,或者Slave重新使用Master一个最近的备份.

如果发生了这种情况,binlog_expire_logs_seconds设置需要重新考虑.

还有一种不常见的情况,Master发现Slave有其没有的GTID SET.这时Master发送: ER_SLAVE_HAS_MORE_GTIDS_THAN_MASTER 信息到Slave.

产生这个问题的原因可能是没有设置SYNC_BINLOG=1.

修正:

可以手工的解决冲突的事务,也可以从复制拓扑中删除Master或者Slave.如果仅是Master缺少事务,可以通过将Master转为Slave,使其接收并应用缺失的事务.

使用GTID设置复制

这里使用最简单的方法设置基于GTID的复制,即可以停止Master Server 和 Slave Server,同时假设已存在的复制环境使用的是基于二进制日志文件位置的复制.

步骤一

同步Server,这一步仅在已使用了非GTID复制模式的环境中需要.比如:

mysql> SET @@GLOBAL.read_only = ON;

这样做的目的是为了使Slave能够同步Master所有非基于GTID的二进制日志事务.因为一旦Server启用了GTID模式,不含有GTID的二进制日志中的事务不能使用.

步骤二

停掉Master和Salve Server,比如:

shell> mysqladmin -uusername -p shutdown

步骤三

启动启用了GTID的服务器,比如:

gtid_mode=ON

enforce-gtid-consistency=ON

注:启动Slave Server添加--skip-slave-start 选项,避免Slave启动时使用之前配置的复制.

步骤四

配置Slave使用基于GTID的 Auto_Positioning,比如:

mysql> CHANGE MASTER TO

　　  > MASTER_HOST = host,

> MASTER_PORT = port,

　　  > MASTER_USER = user,

　　 > MASTER_PASSWORD = password,

　　  > MASTER_AUTO_POSITION = 1;

步骤五

做一个新的备份,因为现在已启用了GTID模式,之前二进制日志中没有包含GTID信息的事务不能应用.这样会导致之前的全备之后做的增量备份不能使用.

步骤六

启动复制并关闭read-only 模式,比如:

mysql> START SLAVE;

mysql> SET @@GLOBAL.read_only = OFF;

补充一下:

无论是使用基于二进制日志文件位置的复制还是使用基于GTID的复制,都是从master复制事务.如果master已经运行很久了,可能产生了大量的事务.这里可能会问题,master的二进制日志可能不好含所有的事务了(gtid_purged不为 0 ).这就需要从master先拷贝一个最近的数据快照.可以通过mysqldump工具的--master-data选项和set-gtid-purged 选项实现.

还有一种可能的问题,master包含所有的二进制日志(gtid_purged=0),但是二进制日志量如果很大,通过复制可能要花费很长时间.可以通过拷贝二进制日志的方式减少同步master所需要的时间.可以通过mysqlbinlog工具的--read-from-remote-master 选项完成, --raw 选项会拷贝二进制日志而不会生成SQL语句.

如果是通过 --raw 选项生成的master二进制日志的副本,可以通过下面方式,在一个mysql客户端命令下应用所有二进制日志,比如:

shell> mysqlbinlog copied-binlog.000001 copied-binlog.000002 | mysql

多源复制

MySQL 提供了多源复制实现,一个Slave Server可以从多个Master Server复制数据.做法是在每个配置复制的语句:CHANGE MASTER TO添加一个 FOR CHANNEL 'CHANNEL_NAME' 子句.

多源复制主要用来复制不同Master的业务数据库,可以通过replicate_wild_do_table配置需要复制的表.

在线切换复制模式

MySQL实现了基于二进制日志复制模式与基于GTID复制模式的在线切换.这个功能的实现主要依赖于GTID_MODE系统变量可以不用重启Server情况下修改.

内置GTID函数

MySQL提供了一些内置的用于操作GTID SET的函数.

 常见复制管理任务

检查复制状态:

Performance_schema 提供了一些与复制相关的性能信息:

mysql> show tables from performance_schema like 'replication%';

比如: replication_connection_configuration表提供了心跳配置信息.默认是slave_net_timeout系统变量配置的一半.

使用SHOW SLAVE STATUS检查单个Slave状态信息.

在Master和Salve端都可以通过SHOW PROCESSLIST命令查看与复制相关进程信息.

暂停Slave Server复制

一般的命令是STOP SLAVE,也可以通过暂停与复制相关的两个线程其中的一个,比如:STOP SLAVE IO_THREAD或者STOP SLAVE SQL_TRHEAD.

IO线程作用:

从Master Server二进制日志中读取EVENTS然后写到中继日志文件.

SQL线程作用:

从中继日志中读取EVENTS然后执行.

复制 Implementation

基于行复制的优势：

All changes can be replicated. This is the safest form of replication

Fewer row locks are required on the master, which thus achieves higher concurrency, for the following types of statements:

　　• INSERT ... SELECT
　　• INSERT statements with AUTO_INCREMENT

　　　　注：MySQL 8.0 中，innodb_autoinc_lock_mode值已经是 2 （interleaved）。这个设置在基于行的复制模式下是安全的，并且具有更好并发性。
　　• UPDATE or DELETE statements with WHERE clauses that do not use keys or do not change most of the examined rows.
Fewer row locks are required on the slave for any INSERT, UPDATE, or DELETE statement.

基于行复制的劣势：

RBR（Row-Based Replication）生成更多的日志、备份和恢复需要花费更多的时间、当写数据的时候，日志锁需要更多的时间，可能导致并发问题。可以通过设置binlog_row_image=minimal来减少日志生成的数量。

生成大量BLOG值的确定性函数需要更长时间复制到Slave中。因为二进制日志中记录的是BLOG字段的值。

在RBR模式下，不能直接查看生成二进制日志的SQL语句，这个可以通过mysqlbinlog工具的--base64-output=decode-rows和--verbose解决。

在RBR模式下，并发插入到MyISAM表是不支持的。

补充一下：

MySQL 8.0.4 之后，RBR模式下，不会记录临时表到二进制日志中。

通过mysqlbinlog工具的--base64-output=decode-rows 选项格式化在RBR模式下二进制日志内容，在应用二进制日志做恢复时，可以通过这个选项查看日志内容。恢复时需要把这选项去掉，不然RBR模式下的EVENTS，mysql客户端程序无法识别。

数据库级复制选项：

replicate-do-db类的选项在RBR与SBR复制模式下影响不同。所以MySQL推荐使用replicate-db-table类的表级选项。

RBL、非事务表、停止Slave：

如果在停止Slave Server时，Slave 线程正在更新非事务表，这样会导致Slave Server的数据不一致问题。所以MySQL建议在停止Slaver Server前，先停止复制，比如：STOP SLAVE或者STOP SLAVE SQL_THREAD。

复制实现的细节

MySQL的复制功能使用三个线程实现，一个在Master，另外两个在Slave。

Binlog Dump Thread

该线程在读取每个用于发送给Slave的二进制日志Event时获取一个锁。一旦Event被读取，即释放锁，即使该Event还没有发送到Slave端。

Slave IO Thread

这个线程读取Binlog Dump 线程发送的Events，然后写到本地的中继日志中。

Slave SQL Thread

读取Slave IO 线程写入的中继日志，执行其中的Events。

注：通过SHOW PROCESSLIST语句或者SHOW SLAVE STATUS语句可以查看相关线程的状态信息。

复制 Channel

每个复制 Channel都有一个接收者线程（IO Thread）、一个或多个应用者线程（SQL Thread）和中继日志。

注：通过slave_parallel_workers 系统变量配置多个SQL 线程。在多源复制中，不能单独为某个Channel配置特定数量的SQL线程。

在MySQL 8.0 中实现了配置绑定到特定Channel的复制过滤规则，这对于复制的Masters中有相同的数据库是有用的。实现的方式是在复制过滤项前加上Channel 名称，比如：

replicate_wild_do_table=channel-1:test1.%
replicate_wild_do_table=channel-2:test2.%

操作单个Channel的一些命令

比如，在Master端，查看RBR模式下的二进制日志内容，一般是通过mysqlbinlog --base64-output=decode-rows -vv类似的做法。再查看日志内容之前，需要确定日志文件的位置，有哪些日志文件，已经当前的日志文件，可以通过下面的命令做这些，比如：

mysql> select @@log_bin_basename;

mysql> show binary logs;

mysql> show master status;

其实MySQL也提供了一种方便的方法，用于查看二进制日志内容，像这样：

mysql> show binlog events in 'binlog.000009';

通过帮助命令：mysql> help show binlog events; 可以了解这个语法的其他使用。

如果是在复制环境中，Slave端可以查看中继日志内容通过mysqlbinlog工具，因为二进制日志和中继日志内容相同。也可以通过SHOW RELAYLOG EVENTS语句查询，比如：

mysql> show relaylog events in 'relay-bin-channel@002d2.000013' for channel 'channel-2';

组复制有两个channel：group_replication_recovery、group_replication_applier

start slave、stop slave、show slave status语句对这两个channel是没有影响的。

reset slave 会重置所有channel。删除所有配置的channel，删除中继日志，重新创建default channel。

复制环境中的中继和状态日志

如果从一个不支持复制日志表的MySQL版本升级到支持的版本，比如MySQL 8.0。在启动mysqld时，可能会因为无法初始化复制相关日志表而产生warning，但是不影响服务器启动。

mysql.slave_relay_log_info表使用的支持事务的存储引擎。在Slave Server应用中继日志事务时也会跟着提交事务到mysql.slave_relay_log_info表。

relay_log_recovery 系统变量：如果开启了这个参数，服务器启动后会立即开始中继日志恢复。做法是：生成一个新的中继日志，将SQL 线程指向这个新的中继日志，初始化IO线程到这个SQL线程的位置。这样做可以防止服务器读取已损坏的中继日志。还有另外一个参数：relay_log_purge。如果开启了这个参数，只要中继日志不需要，就会立即删除。为保证Slave Server crash-safe，这两个参数必须开启。

对于多线程复制Slave（slave_parallel_workers > 0）,由于GAP而产生的不一致问题，relay_log_recovery 选项不能解决。可以通过 START SLAVE UNTIL SQL_AFTER_MTS_GAPS将Slave带入更一致的状态，然后RESET SLAVE。

关于中继日志文件名称的一个可能的问题：

MySQL8.0 中二进制日志默认开启，而且二进制日志文件名也默认不包含主机名。中继日志默认现在还是包含主机名的，如果Slave机器更改了主机名，或者通过这样的Slave产生新的Slave，会因为找不到中继日志而产生一些问题。所以，MySQL建议制定一个非默认主机名。如果出现了这样的问题，MySQL的官档也给出了相应的解决方法。

关于Slave中的状态日志：

mysql.slave_master_info表的信息是由IO线程管理的，记录的master端的二进制日志位置不是实时更新的。

在备份Slave 数据库的时候，mysql.slave_master_info表和mysql.slave_relay_log_info表也可以一起备份。因为他们记录了Slave应用master事务的情况。可以作为恢复时的起点。因为MySQL 8.0以后默认使用表来记录master info 与slave info repository信息。备份mysql schema时也会备份这两个表。如果是之前的版本，使用文件存储master info 与slave info repository信息，备份时，可以备份对应的文件。

复制安全

加密在复制环境中二进制日志传输。

注：master和slave的加密连接需要在服务器支持加密网络连接的前提下，使用CHANGE MASTER TO语句。

加密二进制日志文件和中继日志文件，甚至二进制日志缓存

对应用到特定Channel的事务权限检查。

对于组复制来说，可以设置二进制日志文件、中继日志文件加密和channel权限检查；而二进制日志传输加密可以在组成员通信系统以及分布式恢复中使用；组复制也可以使用白名单来排除非认真主机。