How Do I Enable Binlog and View Binlog Files of My TaurusDB Instance?

1. Log in to the management console.
2. Click in the upper left corner and select a region and project.
3. Click in the upper left corner of the page and choose Databases > TaurusDB.
4. Click the instance name to go to the Basic Information page.
5. In the navigation pane, choose Parameters.
6. Configure parameters as follows:
   • If the kernel version is earlier than 2.0.45.230900, search for the log-bin parameter, select ON from the drop-down list box in the Value column, and click Save. 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.

     To view the kernel version, click the instance name to go to the Basic Information page. In the Configuration area, check the Kernel Version field.

     Figure 1 Viewing the kernel version
     

   • If the kernel version is 2.0.45.230900 or later, search for the rds_global_sql_log_bin parameter, select ON from the drop-down list box in the Value column, and click Save. 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 the binlog is enabled for all threads:

     select @@session.rds_sql_log_bin_inconsistent_count;

     Table 1 Parameter description

     Parameter	Description
     rds_sql_log_bin_inconsistent_count	Specifies the number of users whose the value of sql_log_bin is inconsistent with the value of rds_global_sql_log_bin.

     • If the command output is 0, binlog is successfully enabled for all threads, and all statements can be recorded in binlog. 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 binlog has not been enabled for. The statements executed in the queried threads may not be recorded in binlogs.

         show warnings;

         Figure 2 Querying the IDs of the threads that binlog has not been enabled for
         

         Check your services based on the obtained thread IDs (for example, 53 in Figure 2), 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.

1. Connect to a DB instance. For details, see Connecting to a DB Instance.
2. Run the following command to read binlogs:

   SHOW BINLOG EVENTS [IN 'log_name'] [FROM pos] [LIMIT [offset,] row_count];

   If the system displays a message indicating that you do not have the required permission, run the GRANT command to grant the REPLICATION SLAVE permission to the sub-account.

   GRANT SELECT, REPLICATION SLAVE ON *.* TO 'xx'@'%';

   FLUSH PRIVILEGES;

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

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