安装两台mysql 5.7.35
基于二进制日志文件位置的复制配置
设置基于二进制日志文件位置的复制
1.设置复制源配置
要将源（source）配置为使用基于 二进制日志文件（binary log file）位置的复制（replication），您必须确保启用二进制日志记录（binary logging），并建立唯一的服务器 ID（unique server ID）。
复制拓扑中的每个服务器都必须配置有唯一的服务器 ID，您可以使用 server_id系统变量指定该 ID。此服务器 ID 用于标识复制拓扑中的各个服务器，并且必须是介于 1 和 (2 32 )-1 之间的正整数。server_id您可以通过发出如下语句来动态 更改 值
配置：server_id
SET GLOBAL server_id = 2;
必须在源上启用 二进制日志记录，因为二进制日志是将更改从源复制到其副本的基础。如果使用该选项未在源上启用二进制日志记录
log-bin，则无法进行复制。要在尚未启用的服务器上启用二进制日志记录，您必须重新启动服务器。在这种情况下，关闭 MySQL 服务器并编辑my.cnformy.ini文件。在[mysqld]配置文件的部分中，添加log-bin和server-id选项。如果这些选项已经存在，但已被注释掉，请取消注释这些选项并根据您的需要进行更改。例如，要使用日志文件名前缀启用二进制日志记录mysql-bin，并将服务器 ID 配置为 1，请使用以下行
配置my.cnf 或 my.ini
我的ubuntu安装后，默认配置在/etc/mysql
sudo vi /etc/mysql/mysql.conf.d/mysqld.cnf新增：
[mysqld]
log-bin=mysql-bin
server-id=1注意服务器端配置是 [mysqld] 这个配置下面
其他 bind-address = 可能也需要修改，默认是绑定 127.0.0.1 需要其他ip访问，这个也需要修改
以下选项会影响此过程：
InnoDB为了在使用with 事务 的复制设置中获得最大可能的持久性和一致性 ，您应该在
my.cnf源 文件 中使用
innodb_flush_log_at_trx_commit=1 （默认值）
sync_binlog=1 （默认值）确保 skip_networking未在您的源上启用系统变量。如果网络已被禁用，则副本无法与源通信并且复制失败。
Command-Line Format --innodb-flush-log-at-trx-commit=#System Variable innodb_flush_log_at_trx_commitScope Global Dynamic Yes SET_VAR Hint Applies No Type Enumeration Default Value 1Valid Values
0
1
2MySQL :: MySQL 8.0 Reference Manual :: 15.14 InnoDB Startup Options and System Variables
Command-Line Format --sync-binlog=#System Variable sync_binlogScope Global Dynamic Yes SET_VAR Hint Applies No Type Integer Default Value 1Minimum Value 0Maximum Value 4294967295MySQL :: MySQL 8.0 Reference Manual :: 17.1.6.4 Binary Logging Options and Variables
MySQL :: MySQL 5.7 Reference Manual :: 16.1.2.1 Setting the Replication Source Configuration
进行更改后，重新启动服务器。
sudo service mysql restart2 为复制创建用户
每个副本都使用 MySQL 用户名和密码连接到源，因此源上必须有一个用户帐户，副本可以用来连接。设置副本时，用户名由 命令
MASTER_USER上的选项指定。CHANGE MASTER TO任何帐户都可以用于此操作，前提是它已被授予REPLICATION SLAVE 特权。您可以选择为每个副本创建不同的帐户，或者为每个副本使用相同的帐户连接到源。尽管您不必专门为复制创建帐户，但您应该知道复制用户名和密码以纯文本形式存储在复制元数据存储库中（请参阅 第 16.2.4.2 节，“复制元数据存储库”）。因此，您可能希望创建一个仅对复制过程具有权限的单独帐户，以尽量减少其他帐户受到威胁的可能性。
mysql> CREATE USER 'repl'@'%.example.com' IDENTIFIED BY 'password'; mysql> GRANT REPLICATION SLAVE ON *.* TO 'repl'@'%.example.com';
3 获取复制源的二进制日志坐标
通过使用命令行客户端连接到源在源上启动会话，并通过执行语句刷新所有表并阻止写入FLUSH TABLES WITH READ LOCK语句：
mysql> FLUSH TABLES WITH READ LOCK;
让您发出 FLUSH TABLES语句的客户端保持运行，以便读取锁保持有效。如果你退出客户端，锁就会被释放。
在源上的不同会话中，使用该 SHOW MASTER STATUS语句确定当前二进制日志文件的名称和位置：
mysql > SHOW MASTER STATUS;
+------------------+----------+--------------+------------------+
| File | Position | Binlog_Do_DB | Binlog_Ignore_DB |
+------------------+----------+--------------+------------------+
| mysql-bin.000003 | 73 | test | manual,mysql |
+------------------+----------+--------------+------------------+该
File列显示日志文件的名称，该Position列显示文件中的位置。在这个例子中，二进制日志文件是mysql-bin.000003，位置是 73。记录这些值。稍后在设置副本时需要它们。它们表示副本应该开始处理来自源的新更新的复制坐标。如果源之前在未启用二进制日志记录的情况下运行，则mysqldump --master-dataSHOW MASTER STATUS或mysqldump --master-data显示的日志文件名和位置值为空。在这种情况下，稍后在指定源的日志文件和位置时需要使用的值是空字符串 (
'') 和4.
4 选择数据快照的方法
使用4.1 或者4.2的方法进行数据快照操作
4.1 使用 mysqldump 创建数据快照
要在现有源中创建数据快照，请使用mysqldump工具。数据转储完成后，在开始复制过程之前将此数据导入副本。
以下示例将所有数据库转储到名为 的文件
dbdump.db中，并包含 --master-data自动附加CHANGE MASTER TO副本所需的语句以启动复制过程的选项：
$> mysqldump --all-databases --master-data > dbdump.db
如果不使用 --master-data，则需要手动将所有表锁定在单独的会话中。请参阅第 16.1.2.3 节，“获取复制源的二进制日志坐标”。
可以使用mysqldump工具从转储中排除某些数据库。如果您想选择要包含在转储中的数据库，请不要使用 --all-databases. 选择以下选项之一：
--ignore-table使用选项 排除数据库中的所有表 。
仅命名您希望使用该 --databases选项转储的那些数据库。
4.2 使用原始数据文件创建数据快照
本节介绍如何使用构成数据库的原始文件创建数据快照。将此方法与使用具有复杂缓存或日志记录算法的存储引擎的表一起使用需要额外的步骤来生成完美的“时间点”快照：初始复制命令可能会遗漏缓存信息和日志记录更新，即使您已经获得了全局读锁。存储引擎如何对此做出响应取决于其崩溃恢复能力。
如果您使用InnoDB表，您可以使用 MySQL Enterprise Backup 组件中的mysqlbackup命令来生成一致的快照。此命令记录要在副本上使用的快照对应的日志名称和偏移量。MySQL Enterprise Backup 是一种商业产品，包含在 MySQL Enterprise 订阅中。有关详细信息，请参阅 第 28.2 节，“MySQL 企业备份概述”。
如果源和副本具有不同的、 或 值ft_stopword_file， 并且您正在复制具有全文索引的表， 则此方法也不能可靠地工作 。ft_min_word_lenft_max_word_len
假设上述异常不适用于您的数据库，请使用冷备份 技术获取可靠的
InnoDB表二进制快照： 缓慢关闭MySQL 服务器，然后手动复制数据文件。要在 MySQL 数据文件存在于单个文件系统上时创建表的原始数据快照 MyISAM，您可以使用标准文件复制工具（例如cp或 copy）、远程复制工具（例如 scp或rsync）、归档工具（例如zip或 tar或文件系统快照工具，例如 dump。如果您仅复制某些数据库，请仅复制与这些表相关的那些文件。对于
InnoDB，所有数据库中的所有表都存储在系统表空间中文件，除非您 innodb_file_per_table启用了该选项。复制不需要以下文件：
与
mysql数据库相关的文件。副本的连接元数据存储库文件（如果使用）（请参阅第 16.2.4 节，“中继日志和复制元数据存储库”）。
源的二进制日志文件，二进制日志索引文件除外，如果您要使用它来定位副本的源的二进制日志坐标。
任何中继日志文件。
根据您是否使用
InnoDB表格，选择以下选项之一：如果您使用的是InnoDB表，并且为了获得与原始数据快照最一致的结果，请在此过程中关闭源服务器，如下所示：
1.获取读锁并获取源的状态。请参阅 第 16.1.2.3 节，“获取复制源的二进制日志坐标”。
2.在单独的会话中，关闭源服务器 ：
$> mysqladmin shutdown
3.制作 MySQL 数据文件的副本。以下示例显示了执行此操作的常用方法。您只需选择其中一项：
$> tar cf /tmp/db.tar ./data
$> zip -r /tmp/db.zip ./data
$> rsync --recursive ./data /tmp/dbdata4.重新启动源服务器。
如果您不使用InnoDB 表，则可以从源获取系统快照，而无需按照以下步骤所述关闭服务器：
1.获取读锁并获取源的状态。请参阅 第 16.1.2.3 节，“获取复制源的二进制日志坐标”。
2.制作 MySQL 数据文件的副本。以下示例显示了执行此操作的常用方法。您只需选择其中一项：
在您获得读取锁的客户端中，释放锁：
mysql> UNLOCK TABLES;
创建数据库的存档或副本后，在开始复制过程之前将文件复制到每个副本。
5 设置副本
以下部分描述了如何设置副本。在继续之前，请确保您拥有：
使用必要的配置属性配置源。请参见 第 16.1.2.1 节，“设置复制源配置”。
获取源的状态信息，或在关闭数据快照期间生成的源二进制日志索引文件的副本。请参阅 第 16.1.2.3 节，“获取复制源的二进制日志坐标”。
在源码上，释放了读锁：
mysql> UNLOCK TABLES;
5.1 设置副本配置
每个副本必须具有唯一的服务器 ID，由 server_id系统变量指定。如果您要设置多个副本，则每个副本都必须具有server_id与源和任何其他副本不同的唯一值。如果副本的服务器 ID 尚未设置，或者当前值与您为源服务器或其他副本选择的值冲突，则必须更改它。使用默认 server_id值 0，副本拒绝连接到源。
server_id 您可以通过发出如下语句来动态 更改值
SET GLOBAL server_id = 21;
如果之前设置了默认server_id 值 0，则必须重新启动服务器以使用新的非零服务器 ID 初始化副本。否则，当您更改服务器 ID 时不需要重新启动服务器，除非您进行其他需要它的配置更改。例如，如果在服务器上禁用了二进制日志记录并且您希望为您的副本启用它，则需要重新启动服务器才能启用它。
如果要关闭副本服务器，则可以编辑
[mysqld]配置文件的部分以指定唯一的服务器 ID。例如：
[mysqld]
server-id=215.2 在副本上设置源配置
要将副本设置为与复制源通信，请使用必要的连接信息配置副本。为此，请在副本上执行以下语句，将选项值替换为与您的系统相关的实际值：
mysql> CHANGE MASTER TO
-> MASTER_HOST='source_host_name',
-> MASTER_USER='replication_user_name',
-> MASTER_PASSWORD='replication_password',
-> MASTER_LOG_FILE='recorded_log_file_name',
-> MASTER_LOG_POS=recorded_log_position;复制不能使用 Unix 套接字文件。您必须能够使用 TCP/IP 连接到源 MySQL 服务器。
5.3 在新源和副本之间设置复制
如果没有要导入的先前数据库的快照，请将副本配置为从新源开始复制。
要在源和新副本之间设置复制：
启动副本并连接到它。
执行一条CHANGE MASTER TO 语句来设置源配置。请参阅 第 16.1.2.5.2 节，“在副本上设置源配置”。
在每个副本上执行这些设置步骤。
如果您正在设置新服务器，但有来自不同服务器的现有数据库转储，并且您希望将其加载到复制配置中，也可以使用此方法。通过将数据加载到新源中，数据会自动复制到副本中。
如果您要使用来自不同现有数据库服务器的数据来设置新的复制环境来创建新源，请在新源上运行从该服务器生成的转储文件。数据库更新会自动传播到副本：
$> mysql -h master < fulldb.dump
5.4 使用现有数据设置复制
使用现有数据设置复制时，请在开始复制之前将快照从源传输到副本。将数据导入副本的过程取决于您在源上创建数据快照的方式。
选择以下选项之一：
如果您使用mysqldump：
-
使用该选项启动副本， --skip-slave-start以便不启动复制。
-
导入转储文件：
mysql < fulldb.dump如果您使用原始数据文件创建了快照：
-
将数据文件提取到副本的数据目录中。例如：
$> tar xvf dbdump.tar您可能需要设置文件的权限和所有权，以便副本服务器可以访问和修改它们。
使用该选项启动副本， --skip-slave-start以便不启动复制。
使用来自源的复制坐标配置副本。这告诉副本二进制日志文件和文件中需要开始复制的位置。此外，使用源的登录凭据和主机名配置副本。有关CHANGE MASTER TO所需语句的更多信息，请参阅 第 16.1.2.5.2 节，“在副本上设置源配置”。
启动复制线程：mysql> START SLAVE;
执行此过程后，副本将连接到源并复制自拍摄快照以来在源上发生的任何更新。
如果server_id源的系统变量设置不正确，则副本无法连接到它。同样，如果您没有 server_id为副本正确设置，您会在副本的错误日志中收到以下错误：
复制（Replication）可以将来自一台 MySQL 数据库服务器（源）的数据复制到一台或多台 MySQL 数据库服务器（副本）。复制默认是异步的；副本不需要永久连接即可从源接收更新。根据配置，您可以复制数据库中的所有数据库、选定的数据库甚至选定的表。
Replication enables data from one MySQL database server (the source) to be copied to one or more MySQL database servers (the replicas). Replication is asynchronous by default; replicas do not need to be connected permanently to receive updates from the source. Depending on the configuration, you can replicate all databases, selected databases, or even selected tables within a database.
MySQL 中复制的优点包括：
Advantages of replication in MySQL include:
-
横向扩展解决方案 - 在多个副本之间分散负载以提高性能。在此环境中，所有写入和更新都必须在复制源服务器上进行。然而，读取可能发生在一个或多个副本上。该模型可以提高写入性能（因为源专用于更新），同时显着提高副本数量的读取速度。
-
Scale-out solutions - spreading the load among multiple replicas to improve performance. In this environment, all writes and updates must take place on the replication source server. Reads, however, may take place on one or more replicas. This model can improve the performance of writes (since the source is dedicated to updates), while dramatically increasing read speed across an increasing number of replicas.
-
数据安全——因为数据被复制到副本，并且副本可以暂停复制过程，所以可以在副本上运行备份服务而不会损坏相应的源数据。
-
Data security - because data is replicated to the replica, and the replica can pause the replication process, it is possible to run backup services on the replica without corrupting the corresponding source data.
-
分析 - 可以在源上创建实时数据，而对信息的分析可以在副本上进行，而不会影响源的性能。
-
Analytics - live data can be created on the source, while the analysis of the information can take place on the replica without affecting the performance of the source.
-
远程数据分发——您可以使用复制来创建数据的本地副本以供远程站点使用，而无需永久访问源。
-
Long-distance data distribution - you can use replication to create a local copy of data for a remote site to use, without permanent access to the source.
有关如何在这种情况下使用复制的信息，请参阅 第 16.3 节，“复制解决方案”。
For information on how to use replication in such scenarios, see Section 16.3, “Replication Solutions”.
MySQL 5.7 支持不同的复制方法。传统方法是基于从源的二进制日志中复制事件，并要求源和副本之间同步日志文件和其中的位置。基于全局事务标识符(GTID) 的较新方法是事务性的，因此不需要处理日志文件或这些文件中的位置，这极大地简化了许多常见的复制任务。只要在源上提交的所有事务也已在副本上应用，使用 GTID 的复制可以保证源和副本之间的一致性。有关 MySQL 中 GTID 和基于 GTID 的复制的更多信息，请参阅 第 16.1.3 节，“使用全局事务标识符进行复制”。有关使用基于二进制日志文件位置的复制的信息，请参阅 第 16.1 节，“配置复制”。
MySQL 5.7 supports different methods of replication. The traditional method is based on replicating events from the source's binary log, and requires the log files and positions in them to be synchronized between source and replica. The newer method based on global transaction identifiers (GTIDs) is transactional and therefore does not require working with log files or positions within these files, which greatly simplifies many common replication tasks. Replication using GTIDs guarantees consistency between source and replica as long as all transactions committed on the source have also been applied on the replica. For more information about GTIDs and GTID-based replication in MySQL, see Section 16.1.3, “Replication with Global Transaction Identifiers”. For information on using binary log file position based replication, see Section 16.1, “Configuring Replication”.
MySQL 中的复制支持不同类型的同步。最初的同步类型是单向异步复制，其中一台服务器充当源，而一台或多台其他服务器充当副本。这与作为 NDB Cluster 的特征的 同步复制形成对比（参见第 21 章，MySQL NDB Cluster 7.5 和 NDB Cluster 7.6）。在 MySQL 5.7 中，除了内置的异步复制外，还支持半同步复制。使用半同步复制，在返回到执行事务的会话之前对源块执行的提交，直到至少一个副本确认它已接收并记录事务的事件；请参阅 第 16.3.9 节，“半同步复制”。MySQL 5.7 还支持延迟复制，这样一个副本故意落后于源至少指定的时间量；请参阅 第 16.3.10 节，“延迟复制”。对于需要同步复制的场景 ，使用 NDB Cluster（参见第 21 章，MySQL NDB 集群 7.5 和 NDB 集群 7.6）。
Replication in MySQL supports different types of synchronization. The original type of synchronization is one-way, asynchronous replication, in which one server acts as the source, while one or more other servers act as replicas. This is in contrast to the synchronous replication which is a characteristic of NDB Cluster (see Chapter 21, MySQL NDB Cluster 7.5 and NDB Cluster 7.6). In MySQL 5.7, semisynchronous replication is supported in addition to the built-in asynchronous replication. With semisynchronous replication, a commit performed on the source blocks before returning to the session that performed the transaction until at least one replica acknowledges that it has received and logged the events for the transaction; see Section 16.3.9, “Semisynchronous Replication”. MySQL 5.7 also supports delayed replication such that a replica deliberately lags behind the source by at least a specified amount of time; see Section 16.3.10, “Delayed Replication”. For scenarios where synchronous replication is required, use NDB Cluster (see Chapter 21, MySQL NDB Cluster 7.5 and NDB Cluster 7.6).
有许多解决方案可用于在服务器之间设置复制，使用的最佳方法取决于数据的存在和您使用的引擎类型。有关可用选项的更多信息，请参阅第 16.1.2 节，“设置基于二进制日志文件位置的复制”。
There are a number of solutions available for setting up replication between servers, and the best method to use depends on the presence of data and the engine types you are using. For more information on the available options, see Section 16.1.2, “Setting Up Binary Log File Position Based Replication”.
复制格式有两种核心类型，基于语句的复制 (SBR)，它复制整个 SQL 语句，以及基于行的复制 (RBR)，它只复制更改的行。您还可以使用第三种类型，即基于混合的复制 (MBR)。有关不同复制格式的更多信息，请参阅 第 16.2.1 节，“复制格式”。
There are two core types of replication format, Statement Based Replication (SBR), which replicates entire SQL statements, and Row Based Replication (RBR), which replicates only the changed rows. You can also use a third variety, Mixed Based Replication (MBR). For more information on the different replication formats, see Section 16.2.1, “Replication Formats”.
复制是通过许多不同的选项和变量来控制的。有关更多信息，请参阅 第 16.1.6 节，“复制和二进制日志记录选项和变量”。
Replication is controlled through a number of different options and variables. For more information, see Section 16.1.6, “Replication and Binary Logging Options and Variables”.
您可以使用复制来解决许多不同的问题，包括性能、支持不同数据库的备份，以及作为减轻系统故障的更大解决方案的一部分。有关如何解决这些问题的信息，请参阅 第 16.3 节，“复制解决方案”。
You can use replication to solve a number of different problems, including performance, supporting the backup of different databases, and as part of a larger solution to alleviate system failures. For information on how to address these issues, see Section 16.3, “Replication Solutions”.
有关在复制期间如何处理不同数据类型和语句的注释和提示，包括复制功能、版本兼容性、升级以及潜在问题及其解决方案的详细信息，请参阅第 16.4 节，“复制说明和提示”。有关 MySQL 复制新手经常提出的一些问题的答案，请参阅第 A.14 节，“MySQL 5.7 常见问题解答：复制”。
For notes and tips on how different data types and statements are treated during replication, including details of replication features, version compatibility, upgrades, and potential problems and their resolution, see Section 16.4, “Replication Notes and Tips”. For answers to some questions often asked by those who are new to MySQL Replication, see Section A.14, “MySQL 5.7 FAQ: Replication”.
有关复制的实现、复制如何工作、二进制日志的过程和内容、后台线程以及用于决定如何记录和复制语句的规则的详细信息，请参阅 第 16.2 节，“复制实现”。
For detailed information on the implementation of replication, how replication works, the process and contents of the binary log, background threads and the rules used to decide how statements are recorded and replicated, see Section 16.2, “Replication Implementation”.
MySQL :: MySQL 5.7 Reference Manual :: 16 Replication
16.1 配置复制
16.1.1 基于二进制日志文件位置的复制配置概述
16.1.2 设置基于二进制日志文件位置的复制
16.1.3 使用全局事务标识符进行复制
16.1.4 更改在线服务器上的复制模式
16.1.5 MySQL 多源复制
16.1.6 复制和二进制日志记录选项和变量
16.1.2 Setting Up Binary Log File Position Based Replication16.1.3 Replication with Global Transaction Identifiers
16.1.4 Changing Replication Modes on Online Servers
16.1.5 MySQL Multi-Source Replication
本节介绍如何配置 MySQL 中可用的不同类型的复制，并包括复制环境所需的设置和配置，包括创建新复制环境的分步说明。本节的主要组成部分是：
-
有关使用二进制日志文件位置设置两个或多个服务器进行复制的指南， 第 16.1.2 节，“设置基于二进制日志文件位置的复制”，处理服务器的配置并提供在源之间复制数据的方法和复制品。
-
有关使用 GTID 事务设置两个或多个服务器进行复制的指南，第 16.1.3 节，“使用全局事务标识符进行复制”，处理服务器的配置。
-
二进制日志中的事件使用多种格式记录。这些被称为基于语句的复制 (SBR) 或基于行的复制 (RBR)。第三种类型，混合格式复制 (MIXED)，在适当的时候自动使用 SBR 或 RBR 复制来利用 SBR 和 RBR 格式的优势。第 16.2.1 节，“复制格式”中讨论了不同的格式 。
-
第 16.1.6 节，“复制和二进制日志记录选项和变量” 中提供了有关适用于复制的不同配置选项和变量的详细信息 。
-
一旦开始，复制过程几乎不需要管理或监控。但是，有关您可能想要执行的常见任务的建议，请参阅 第 16.1.7 节，“常见的复制管理任务”。
3169
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
