This topic describes the SQL statements that can be used to replicate data between MySQL servers based on binary log files.

How the binary log feature supports data replication

  • Binary log files of PolarDB-X are generated based on physical binary logs stored on data nodes. The details of distributed transactions are removed from the binary logs. Only non-distributed transactions are retained in the binary logs. In addition, the binary logs are compatible with the binary log format and dump protocol of MySQL. You can replicate transaction logs in a PolarDB-X instance in the same manner in which you replicate transaction logs in a standalone MySQL database.
  • PolarDB-X supports the binary log feature in two modes: single-stream mode and multi-stream mode. For more information, see Binary logs.
  • PolarDB-X uses a variety of protocols and algorithms to ensure the stability and reliability of binary logs:
    • The recovery time objective (RTO) is less than 30 seconds for a high-availability (HA) switchover or node scaling in the change data capture (CDC) component.
    • The scaling of data nodes triggers only one link restart, and the RTO is less than 20 seconds.
    • The binary log feature does not block DDL operations. DDL operations are completely performed online.

Limits

  • If the global transaction identifier (GTID) mode is enabled for your PolarDB-X instance, data replication is not supported.
  • If you use single-stream binary logs, distributed transactions can be merged only when the transaction policy is set to Timestamp Oracle (TSO). TSO ensures stronger data consistency.

SQL statements supported by the source instance for data replication

SQL statements supported by the destination instance for data replication

  • If the destination instance is a native MySQL server or a MySQL server that is consistent with a native MySQL server in SQL syntax, the SQL statements that are used for MySQL replication are supported.
  • If you want to replicate multi-stream binary logs, you must create a replication link for each log stream. Each log stream can be regarded as a log stream from a standalone MySQL database.
Note If the destination instance is a PolarDB-X instance, statements that are used for MySQL replication are not supported.
  • Execute the following statement to configure information about the source instance in the destination instance:
    CHANGE MASTER TO option [, option] ... [ channel_option ]
    
    option: {
        MASTER_BIND = 'interface_name'
      | MASTER_HOST = 'host_name'
      | MASTER_USER = 'user_name'
      | MASTER_PASSWORD = 'password'
      | MASTER_PORT = port_num
      | PRIVILEGE_CHECKS_USER = {'account' | NULL}
      | REQUIRE_ROW_FORMAT = {0|1}
      | REQUIRE_TABLE_PRIMARY_KEY_CHECK = {STREAM | ON | OFF}
      | ASSIGN_GTIDS_TO_ANONYMOUS_TRANSACTIONS = {OFF | LOCAL | uuid}
      | MASTER_LOG_FILE = 'source_log_name'
      | MASTER_LOG_POS = source_log_pos
      | MASTER_AUTO_POSITION = {0|1}
      | RELAY_LOG_FILE = 'relay_log_name'
      | RELAY_LOG_POS = relay_log_pos
      | MASTER_HEARTBEAT_PERIOD = interval
      | MASTER_CONNECT_RETRY = interval
      | MASTER_RETRY_COUNT = count
      | SOURCE_CONNECTION_AUTO_FAILOVER = {0|1}
      | MASTER_DELAY = interval
      | MASTER_COMPRESSION_ALGORITHMS = 'value'
      | MASTER_ZSTD_COMPRESSION_LEVEL = level
      | MASTER_SSL = {0|1}
      | MASTER_SSL_CA = 'ca_file_name'
      | MASTER_SSL_CAPATH = 'ca_directory_name'
      | MASTER_SSL_CERT = 'cert_file_name'
      | MASTER_SSL_CRL = 'crl_file_name'
      | MASTER_SSL_CRLPATH = 'crl_directory_name'
      | MASTER_SSL_KEY = 'key_file_name'
      | MASTER_SSL_CIPHER = 'cipher_list'
      | MASTER_SSL_VERIFY_SERVER_CERT = {0|1}
      | MASTER_TLS_VERSION = 'protocol_list'
      | MASTER_TLS_CIPHERSUITES = 'ciphersuite_list'
      | MASTER_PUBLIC_KEY_PATH = 'key_file_name'
      | GET_MASTER_PUBLIC_KEY = {0|1}
      | NETWORK_NAMESPACE = 'namespace'
      | IGNORE_SERVER_IDS = (server_id_list)
    }
    
    channel_option:
        FOR CHANNEL channel
    
    server_id_list:
        [server_id [, server_id] ... ]
  • Execute the following statement to start data replication:
    START {SLAVE | REPLICA}
  • Execute the following statement to stop data replication:
    STOP {SLAVE | REPLICA}
  • Execute the following statement to reset data replication. You must stop data replication before you execute the following statement:
    RESET {SLAVE | REPLICA} [ALL] [channel_option]
    
    channel_option:
        FOR CHANNEL channel