17.1.2.8 Adding Replicas to a Replication Environment
这是一篇协同翻译的文章,你可以点击『我来翻译』按钮来参与翻译。
You can add another replica to an existing replication configuration without stopping the source server. To do this, you can set up the new replica by copying the data directory of an existing replica, and giving the new replica a different server ID (which is user-specified) and server UUID (which is generated at startup).
Note
If the replication source server or existing replica that you are copying to create the new replica has any scheduled events, ensure that these are disabled on the new replica before you start it. If an event runs on the new replica that has already run on the source, the duplicated operation causes an error. The Event Scheduler is controlled by the
event_scheduler
system variable, which defaults toON
from MySQL 8.0, so events that are active on the original server run by default when the new replica starts up. To stop all events from running on the new replica, set theevent_scheduler
system variable toOFF
orDISABLED
on the new replica. Alternatively, you can use theALTER EVENT
statement to set individual events toDISABLE
orDISABLE ON SLAVE
to prevent them from running on the new replica. You can list the events on a server using theSHOW
statement or the Information SchemaEVENTS
table. For more information, see Section 17.5.1.16, “Replication of Invoked Features”.
As an alternative to creating a new replica in this way, MySQL Server's clone plugin can be used to transfer all the data and replication settings from an existing replica to a clone. For instructions to use this method, see Section 5.6.7.7, “Cloning for Replication”.
To duplicate an existing replica without cloning, follow these steps:
-
Stop the existing replica and record the replica status information, particularly the source binary log file and relay log file positions. You can view the replica status either in the Performance Schema replication tables (see Section 27.12.11, “Performance Schema Replication Tables”), or by issuing
SHOW REPLICA STATUS
as follows:mysql> STOP SLAVE; mysql> SHOW SLAVE STATUS\G Or from MySQL 8.0.22: mysql> STOP REPLICA; mysql> SHOW REPLICA STATUS\G
-
Shut down the existing replica:
$> mysqladmin shutdown
-
Copy the data directory from the existing replica to the new replica, including the log files and relay log files. You can do this by creating an archive using tar or
WinZip
, or by performing a direct copy using a tool such as cp or rsync.Important
- Before copying, verify that all the files relating to the existing replica actually are stored in the data directory. For example, the
InnoDB
system tablespace, undo tablespace, and redo log might be stored in an alternative location.InnoDB
tablespace files and file-per-table tablespaces might have been created in other directories. The binary logs and relay logs for the replica might be in their own directories outside the data directory. Check through the system variables that are set for the existing replica and look for any alternative paths that have been specified. If you find any, copy these directories over as well. - During copying, if files have been used for the replication metadata repositories (see Section 17.2.4, “Relay Log and Replication Metadata Repositories”), ensure that you also copy these files from the existing replica to the new replica. If tables have been used for the repositories, which is the default from MySQL 8.0, the tables are in the data directory.
- After copying, delete the
auto.cnf
file from the copy of the data directory on the new replica, so that the new replica is started with a different generated server UUID. The server UUID must be unique.
A common problem that is encountered when adding new replicas is that the new replica fails with a series of warning and error messages like these:
071118 16:44:10 [Warning] Neither --relay-log nor --relay-log-index were used; so replication may break when this MySQL server acts as a replica and has his hostname changed!! Please use '--relay-log=new_replica_hostname-relay-bin' to avoid this problem. 071118 16:44:10 [ERROR] Failed to open the relay log './old_replica_hostname-relay-bin.003525' (relay_log_pos 22940879) 071118 16:44:10 [ERROR] Could not find target log during relay log initialization 071118 16:44:10 [ERROR] Failed to initialize the master info structure
This situation can occur if the
relay_log
system variable is not specified, as the relay log files contain the host name as part of their file names. This is also true of the relay log index file if therelay_log_index
system variable is not used. For more information about these variables, see Section 17.1.6, “Replication and Binary Logging Options and Variables”.To avoid this problem, use the same value for
relay_log
on the new replica that was used on the existing replica. If this option was not set explicitly on the existing replica, use*
existing_replica_hostname*-relay-bin
. If this is not possible, copy the existing replica's relay log index file to the new replica and set therelay_log_index
system variable on the new replica to match what was used on the existing replica. If this option was not set explicitly on the existing replica, use*
existing_replica_hostname*-relay-bin.index
. Alternatively, if you have already tried to start the new replica after following the remaining steps in this section and have encountered errors like those described previously, then perform the following steps:-
If you have not already done so, issue
STOP REPLICA
on the new replica.If you have already started the existing replica again, issue
STOP REPLICA
on the existing replica as well. -
Copy the contents of the existing replica's relay log index file into the new replica's relay log index file, making sure to overwrite any content already in the file.
-
Proceed with the remaining steps in this section.
- Before copying, verify that all the files relating to the existing replica actually are stored in the data directory. For example, the
-
When copying is complete, restart the existing replica.
-
On the new replica, edit the configuration and give the new replica a unique server ID (using the
server_id
system variable) that is not used by the source or any of the existing replicas. -
Start the new replica server, ensuring that replication does not start yet by specifying the
--skip-slave-start
option, or from MySQL 8.0.24, theskip_slave_start
system variable. Use the Performance Schema replication tables or issueSHOW REPLICA STATUS
to confirm that the new replica has the correct settings when compared with the existing replica. Also display the server ID and server UUID and verify that these are correct and unique for the new replica. -
Start the replica threads by issuing a
START REPLICA
statement. The new replica now uses the information in its connection metadata repository to start the replication process.
本文中的所有译文仅用于学习和交流目的,转载请务必注明文章译者、出处、和本文链接
我们的翻译工作遵照 CC 协议,如果我们的工作有侵犯到您的权益,请及时联系我们。