17.1.2.5 选择创建数据快照的方法

8.0

8.0

如果主节点数据库已经存在一些数据，则需要在开始同步之前先将已有数据复制到每个副本节点。
要选择适当的数据库导出方法，可以在以下选项之间进行选择：

• 使用 mysqldump 工具导出想要同步的所有数据库的转储文件。这是推荐的方法，特别是在使用 InnoDB 的时候。

• 如果你的数据库存储在二进制可移植文件中，你可以将原始数据文件复制到副本节点中。这可能比在每个副本节点上使用 mysqldump 导入文件更有效，因为它跳过了在重新执行 INSERT 语句时更新索引的开销。但是如果你使用 InnoDB 这样的存储引擎则不建议使用此方法。

• 使用 MySQL 的克隆插件将所有数据从一个副本节点复制到另一个克隆副本节点。有关使用此方法的说明，请参见第5.6.7.7节 「副本节点的克隆」。

Tip
要部署多个 MySQL 实例，您可以使用 InnoDB Cluster，它能够使你在 MySQL Shell 中轻松管理多个 MySQL 服务器实例。InnoDB Cluster在一个可编程环境中包装了 MySQL Group Replication，使你能够轻松部署 MySQL 实例集群以实现高可用性。此外，InnoDB Cluster 实现了与 MySQL Router 的无缝接口，使您的应用程序无需编写自己的故障转移过程就可以连接到集群。对于不需要高可用性的类似用例，您可以使用 InnoDB ReplicaSet。MySQL Shell 的安装说明可以在此处找到。

MIsakas 翻译于 7个月前

0 重译

由 MArtian 审阅

17.1.2.5.1 使用 mysqldump 创建数据快照

要创建主节点数据库中数据的快照，这里推荐使用  mysqldump  工具。数据快照创建好后，请在开始同步之前之前将快照导入到副本节点中。

下面的命令将为所有数据库创建快照，并导出到 dbdump.db 的文件中，通过指定  --master-data 选项会自动附加所需的 CHANGE REPLICATION SOURCE TO 或 CHANGE MASTER TO 语句，以便在副本节点上启动同步进程：

$> mysqldump --all-databases --master-data > dbdump.db

Note

如果您不使用 --master-data 选项，则需要在单独的会话中手动锁定所有表。请参见第17.1.2.4节 「获取复制源二进制日志坐标」 。

mysqldump 工具可手动指定导出哪些数据库。如果你需要手动指定，请先去掉 --all-databases 选项。并选择以下其中一种选项替代：

• 使用 --ignore-table 选项排除数据库中的所有表。

• 使用 --databases 选项指定想要导出的数据库

  Note
  此段需要重新翻译，请有能力的译者提交改进
  默认情况下，如果主节点启用了 GTIDs（gtid_mode=ON），mysqldump 会在转储输出中包含源数据库中gtid_executed集合中的GTIDs，以将它们添加到副本的gtid_purged集合中。如果您只转储特定的数据库或表，则需要注意mysqldump包含的值包括源数据库中gtid_executed集合中的所有事务的GTIDs，即使这些事务更改了数据库的受抑制的部分或其他未包含在部分转储中的服务器上的数据库。请检查mysqldump的--set-gtid-purged选项的描述，以查找您正在使用的MySQL服务器版本的默认行为结果，以及如何更改行为，如果此结果不适合您的情况。

MIsakas 翻译于 7个月前

0 重译

由 MArtian 审阅

For more information, see Section 4.5.4, “mysqldump — A Database Backup Program”.

To import the data, either copy the dump file to the replica, or access the file from the source when connecting remotely to the replica.

17.1.2.5.2 Creating a Data Snapshot Using Raw Data Files

This section describes how to create a data snapshot using the raw files which make up the database. Employing this method with a table using a storage engine that has complex caching or logging algorithms requires extra steps to produce a perfect “point in time” snapshot: the initial copy command could leave out cache information and logging updates, even if you have acquired a global read lock. How the storage engine responds to this depends on its crash recovery abilities.

If you use InnoDB tables, you can use the mysqlbackup command from the MySQL Enterprise Backup component to produce a consistent snapshot. This command records the log name and offset corresponding to the snapshot to be used on the replica. MySQL Enterprise Backup is a commercial product that is included as part of a MySQL Enterprise subscription. See Section 30.2, “MySQL Enterprise Backup Overview” for detailed information.

This method also does not work reliably if the source and replica have different values for ft_stopword_file, ft_min_word_len, or ft_max_word_len and you are copying tables having full-text indexes.

Assuming the above exceptions do not apply to your database, use the cold backup technique to obtain a reliable binary snapshot of InnoDB tables: do a slow shutdown of the MySQL Server, then copy the data files manually.

To create a raw data snapshot of MyISAM tables when your MySQL data files exist on a single file system, you can use standard file copy tools such as cp or copy, a remote copy tool such as scp or rsync, an archiving tool such as zip or tar, or a file system snapshot tool such as dump. If you are replicating only certain databases, copy only those files that relate to those tables. For InnoDB, all tables in all databases are stored in the system tablespace files, unless you have the innodb_file_per_table option enabled.

The following files are not required for replication:

• Files relating to the mysql database.

• The replica's connection metadata repository file master.info, if used; the use of this file is now deprecated (see Section 17.2.4, “Relay Log and Replication Metadata Repositories”).

• The source's binary log files, with the exception of the binary log index file if you are going to use this to locate the source binary log coordinates for the replica.

• Any relay log files.

Depending on whether you are using InnoDB tables or not, choose one of the following:

If you are using InnoDB tables, and also to get the most consistent results with a raw data snapshot, shut down the source server during the process, as follows:

1. Acquire a read lock and get the source's status. See Section 17.1.2.4, “Obtaining the Replication Source Binary Log Coordinates”.

2. In a separate session, shut down the source server:

   $> mysqladmin shutdown

3. Make a copy of the MySQL data files. The following examples show common ways to do this. You need to choose only one of them:

   $> tar cf /tmp/db.tar ./data
   $> zip -r /tmp/db.zip ./data
   $> rsync --recursive ./data /tmp/dbdata

4. Restart the source server.

If you are not using InnoDB tables, you can get a snapshot of the system from a source without shutting down the server as described in the following steps:

1. Acquire a read lock and get the source's status. See Section 17.1.2.4, “Obtaining the Replication Source Binary Log Coordinates”.

2. Make a copy of the MySQL data files. The following examples show common ways to do this. You need to choose only one of them:

   $> tar cf /tmp/db.tar ./data
   $> zip -r /tmp/db.zip ./data
   $> rsync --recursive ./data /tmp/dbdata

3. In the client where you acquired the read lock, release the lock:

   mysql> UNLOCK TABLES;

Once you have created the archive or copy of the database, copy the files to each replica before starting the replication process.