tencent cloud

Data Transfer Service

Binlog Parameter Check

Unduh
Mode fokus
Ukuran font
Terakhir diperbarui: 2026-11-05 10:31:39
Diterjemahkan oleh AI

Checking Details

You need to configure the source database's binlog parameters in compliance with the following requirements. If the verification fails, fix it as instructed in this section.
The log_bin variable must be set to ON.
The binlog_format variable must be set to ROW.
For source databases running MySQL version 5.6 or later, the gtid_mode parameter can only be set to ON or OFF. It is recommended to set gtid_mode to ON. Setting it to OFF generates an alarm, while setting it to ON_PERMISSIVE or OFF_PERMISSIVE causes an error.
The server_id parameter must be manually set to a value other than 0.
It is not allowed to set do_db and ignore_db.
If the source instance is a replica, the log_slave_updates variable must be set to ON.
It is recommended to retain binlogs in the source database for at least 3 days. Otherwise, if the task is paused/interrupted for a period longer than the Binlog retention period, the task may fail due to the inability to resume.

Fix

Enabling the Binlog Feature

log_bin controls the binlog option. You need to enable the binlog feature to record all database table structures and data change logs.
If such an error occurs, see the following instructions to fix it.
1. Log in to the source database.
2. Modify the my.cnf configuration file for the source database by referring to the following content.
The modification of the log_bin parameter only takes effect after the database is restarted. Therefore, if errors are also reported for the binlog_format, server_id, binlog_row_image, and expire_logs_days parameters in the verification phase, modify all these parameters before restarting the database so that all the modifications can take effect.
Note:
The default path for the my.cnf configuration file is /etc/my.cnf. The actual path in your environment may vary.
log_bin = MYSQL_BIN
binlog_format = ROW
server_id = 2 // It is recommended to set this parameter to an integer greater than 1. This is only an example.
binlog_row_image = FULL
expire_logs_days = 3 // Modify the retention period for binlogs. It is recommended to set this to 3 days or more.
3. Run the following commands to restart the source database.
[$Mysql_Dir]/bin/mysqladmin -u root -p shutdown
[$Mysql_Dir]/bin/safe_mysqld &
Note:
[$Mysql_Dir] refers to the installation path of the source database. Replace it with the actual installation directory of the source database.
4. Check whether the binlog feature is enabled.
show variables like '%log_bin%';
The system displays results similar to the following:
mysql> show variables like '%log_bin%';
+------------------+-------+
| Variable_name | Value |
+------------------+-------+
| log_bin | ON |
+------------------+-------+
1 row in set (0.00 sec)
Run the corresponding commands below to view the modification results for other parameters.
show variables like '%binlog_format%';
show variables like '%binlog_row_image%';
show global variables like '%server_id%';
5. Execute the check task again.

Modifying the binlog_format Parameter

binlog_format refers to the recording modes for binlogs. The following three modes are available:
STATEMENT: Every SQL statement that modifies data is recorded in the master's binlog. During replication, the replica executes the same SQL statements that were originally executed on the master. This mode can reduce the volume of binlog data. However, it causes the replica to incorrectly replicate certain specific functions.
ROW: The binlog will log the modification of each data row, and the same data is modified on the replica. This mode guarantees the correct master-to-replica replication but increases the binlog size.
MIXED: This mode is a combination of the previous two. MySQL determines the appropriate logging format for each specific SQL statement executed, selecting one from STATEMENT and ROW.
To ensure correct replication between the master and replica, the binlog_format parameter must be set to ROW. If such an error occurs, see the following instructions to fix it.
Note:
To change this parameter, you need to reset all database connections for the change to take effect. If the source database is a replica, you also need to restart the master-replica synchronization SQL thread to prevent current service connections from continuing to write data using the pre-change mode.
1. Log in to the source database.
2. Run the following command to modify binlog_format.
set global binlog_format = ROW;
3. Restart the thread for the configuration to take effect. Then, run the following command to check whether the parameter modification has taken effect.
show variables like '%binlog_format%';
The system displays results similar to the following:
mysql> show variables like '%binlog_format%';
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| binlog_format | ROW |
+---------------+-------+
1 row in set (0.00 sec)
4. Execute the check task again.

Modifying the gtid_mode Parameter

GTID (Global Transaction Identifier) uniquely identifies a transaction in the binlog. Using GTID prevents data chaos or master-replica inconsistency caused by repeated transaction execution. GTID is a new feature in MySQL 5.6, so this issue exists in MySQL 5.6 and later versions. DTS only supports setting gtid_mode to ON or OFF. It is recommended to set gtid_mode to ON. Otherwise, an alarm is generated during verification.
The alarm does not affect the migration or synchronization task but affects the business. After GTID is set, if HA switchover occurs on the source database during incremental data synchronization, DTS performs switchover and reconnection, which is almost imperceptible to the task. If GTID is not set, the task will fail after disconnection and cannot be resumed.
The valid values for gtid_mode are as follows. When modifying the value of gtid_mode, you must change it step by step through the following four values. For example, to change it from OFF to ON, follow the modification sequence for gtid_mode: OFF <-> OFF_PERMISSIVE <-> ON_PERMISSIVE <-> ON.
OFF: All new transactions on the master and all transactions on the replica must be anonymous transactions.
OFF_PERMISSIVE: New transactions on the master are anonymous transactions. However, transactions on the replica can be a mixture of anonymous and GTID transactions or anonymous transactions, but they cannot be only GTID transactions.
ON_PERMISSIVE: New transactions on the master are GTID transactions. Transactions on the replica can be either anonymous or GTID transactions.
ON: New transactions on the master and transactions on the replica must be GTID transactions.
If such an alarm occurs, follow the instructions below to fix it:
1. Log in to the source database.
2. Set gtid_mode = OFF_PERMISSIVE on both sides of the master-replica replication structure. For MySQL versions earlier than 5.7.6, you need to modify the my.cnf configuration file and restart the database for the setting to take effect. For MySQL 5.7.6 and later, you can modify it through a global command without restarting the database, but you need to reset all business connections.
set global gtid_mode = OFF_PERMISSIVE;
3. Set gtid_mode = ON_PERMISSIVE on both sides of the master-replica replication structure.
set global gtid_mode = ON_PERMISSIVE;
4. Run the following command on each instance node to check whether anonymous transactions are consumed. A parameter value of 0 indicates that they are consumed.
show variables like '%ONGOING_ANONYMOUS_TRANSACTION_COUNT%';
The system displays results similar to the following:
mysql> show variables like '%ONGOING_ANONYMOUS_TRANSACTION_COUNT%';
+-------------------------------------+-------+
| Variable_name | Value |
+-------------------------------------+-------+
| Ongoing_anonymous_transaction_count | 0 |
+-------------------------------------+-------+
1 row in set (0.00 sec)
5. Set gtid_mode = ON on both sides of the master-replica replication structure.
set global gtid_mode = ON;
6. Add the following content to the my.cnf file and restart the database for the initial values to take effect.
Note:
The default path for the my.cnf configuration file is /etc/my.cnf. The actual path in your environment may vary.
gtid_mode = on
enforce_gtid_consistency = on
7. Execute the check task again.

Modifying the server_id Parameter

The server_id parameter must be set manually and cannot be 0. The default value of this parameter is 1, but the configuration may not be correct even if the queried parameter value is 1. You need to manually set it.
1. Log in to the source database.
2. Run the following command to modify the server_id parameter.
set global server_id = 2; // It is recommended to set this parameter to an integer greater than 1. This is only an example.
3. Run the following command to check whether the parameter modification has taken effect.
show global variables like '%server_id%';
The system displays results similar to the following:
mysql> show global variables like '%server_id%';
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| server_id | 2 |
+---------------+-------+
1 row in set (0.00 sec)
4. Execute the check task again.

Deleting the do_db and ignore_db Settings

Binlogs record all DDL and DML statements executed by the database. The do_db and ignore_db parameters define the filter criteria for binlog records.
binlog_do_db: records binlogs only for specified databases. By default, all logs are recorded.
binlog_ignore_db: does not record logs for specified databases.
Setting do_db and ignore_db can cause incomplete binlog records for some cross-database operations and lead to master-replica replication exceptions. Therefore, it is not recommended to set them. If such an error occurs, see the following instructions to fix it:
1. Log in to the source database.
2. Modify the my.cnf configuration file for the source database to remove the do_db and ignore_db settings.
Note:
The default path for the my.cnf configuration file is /etc/my.cnf. The actual path in your environment may vary.
3. Run the following commands to restart the source database.
[$Mysql_Dir]/bin/mysqladmin -u root -p shutdown
[$Mysql_Dir]/bin/safe_mysqld &
Note:
[$Mysql_Dir] refers to the installation path of the source database. Replace it with the actual installation directory of the source database.
4. Check whether the parameter modification has taken effect.
show master status;
The system displays results similar to the following:
mysql> show master status;
+---------------+----------+--------------+------------------+-------------------+
| File | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set |
+---------------+----------+--------------+------------------+-------------------+
| binlog.000011 | 154 | | | |
+---------------+----------+--------------+------------------+-------------------+
5. Execute the check task again.

Modifying the log_slave_updates Parameter

In a master-replica replication structure, after the log-bin parameter is enabled for a replica, data operations on the replica can be recorded in its binlog. However, data replication from the master to the replica is not recorded in the binlog. Therefore, if the replica acts as a master for other replicas, you need to enable the log_slave_updates parameter.
1. Log in to the source database.
2. Add the following content to the my.cnf configuration file for the source database.
Note:
The default path for the my.cnf configuration file is /etc/my.cnf. The actual path in your environment may vary.
log_slave_updates = ON
3. Run the following commands to restart the source database.
[$Mysql_Dir]/bin/mysqladmin -u root -p shutdown
[$Mysql_Dir]/bin/safe_mysqld &
Note:
[$Mysql_Dir] refers to the installation path of the source database. Replace it with the actual installation directory of the source database.
4. Check whether the configuration has taken effect.
show variables like '%log_slave_updates%';
The system displays results similar to the following:
mysql> show variables like '%log_slave_updates%';
+-------------------+-------+
| Variable_name | Value |
+-------------------+-------+
| log_slave_updates | ON |
+-------------------+-------+
1 row in set (0.00 sec)
5. Execute the check task again.

Bantuan dan Dukungan

Apakah halaman ini membantu?

masukan