Enabling Local Binlogs

Scenarios

Local binlogs refer to the binlogs stored within an instance and consume its storage space. This section describes how to enable local binlogs and the impact on TaurusDB performance after binlogs are enabled.

Billing

Binlogs stored within an instance consume the storage space of the instance. For details about the unit price of storage space, see "Storage Space Price" in TaurusDB Pricing Details.

Impact on Performance

Enabling binlogs does not affect SELECT operations, but affects INSERT, UPDATE, DELETE and other write operations.

There are no significant differences between TaurusDB binlogs and open-source MySQL binlogs. The binlog syntax of TaurusDB is fully compatible with that of the open-source MySQL.

Enabling Local Binlogs

1. Log in to the TaurusDB console.
2. Click the instance name to go to the Basic Information page.
3. In the navigation pane, choose Parameters.
4. Set the log parameter based on the kernel version. You can check the kernel version in the Configuration > Kernel Version area on the Basic Information page.
   • Kernel version < 2.0.45.230900

     Enter log-bin in the search box and click the search button. Locate the displayed parameter, select ON from the Value drop-down list. Click Save above the parameter list. The modified parameter value is applied only after the DB instance is rebooted. For details about the impact and precautions of rebooting a DB instance, see Rebooting a DB Instance.

   • Kernel version ≥ 2.0.45.230900

     Enter rds_global_sql_log_bin in the search box and click the search button. Locate the displayed parameter, select ON from the Value drop-down list. Click Save above the parameter list. The modified parameter value is applied immediately. You do not need to reboot the DB instance.

     After this parameter is changed, connect to the database and run the following command to check whether binlogs are enabled for all threads:

     select @@session.rds_sql_log_bin_inconsistent_count;

     Table 1 Status variable description

     Status Variable	Description
     rds_sql_log_bin_inconsistent_count	Specifies the number of users whose sql_log_bin setting differs from the rds_global_sql_log_bin setting.

     • If the command output is 0, binlogs are successfully enabled for all threads, and all statements can be recorded in binlogs. Then a full backup can be performed.
     • If the command output is not 0, perform the following operations:
       • If you connect to the DB instance through DAS, view warnings on the Messages tab page of the executed SQL statements.
       • If you connect to the DB instance through the mysql client, run the following command to check the IDs of the threads that binlogs have not been enabled for. The statements executed in the queried threads may not be recorded in binlogs.

         show warnings;

         Figure 1 Querying the IDs of the threads that binlogs have not been enabled for
         

         Check your services based on the obtained thread IDs (for example, 53 in Figure 1), commit or roll back transactions and execute new transactions (for example, SELECT 1;) in a timely manner based on service requirements, or disconnect idle connections and reconnect them.

5. (Optional) On the Parameters tab, set binlog_expire_logs_seconds.
   • When a new binlog file is generated, any existing binlog files that have expired will be deleted.
   • If no new binlog file is generated, historical binlog files will not be deleted even if they have expired. To delete the binlog files immediately, connect to the database and run flush logs; to forcibly generate a new binlog file.