You can monitor MySQL replication activity and metrics for HeatWave and External MySQL DB systems in Database Management.

MySQL has a built-in feature that allows the replication of data from a MySQL server to one or more MySQL servers, allowing for seamless failover, distributed read operations, and efficient data redundancy. MySQL replication provides flexibility through various replication types, each with distinct characteristics and benefits tailored to specific use cases. Here are a few important MySQL replication types:

• Asynchronous Replication: Traditional MySQL replication, which enables data from one MySQL server, which is known as a source, to be copied to one or more MySQL servers known as replicas. Replication is asynchronous by default; replicas need not be connected permanently to receive updates from a source. Asynchronous replication can be configured to establish pathways for data transfer in the following ways:
  • Inbound Replication: Uses a replication channel configured in this MySQL server to receive and apply transactions from an external source.
  • Outbound Replication: Uses a replication channel to send transactions from this MySQL server to another location. The channel is always configured on the replica. If the replica is a HeatWave DB system, the channel is configured in the HeatWave service.
• Group Replication: High Availability solution that enables a set of MySQL servers to function as a cohesive group, ensuring data consistency and fault tolerance. Each MySQL server maintains a complete copy of the data, and communicates with other group members through message passing. The communication layer provides a set of guarantees such as atomic message and total order message delivery.

For information on:

• MySQL replication, see Replication
• Group replication, see Group Replication
• MySQL replication types, see Replication Technologies
• Inbound and Outbound replication in the HeatWave service, see Inbound Replication and Outbound Replication

In Database Management, you can monitor replication for a DB system, which is crucial to ensure data consistency, performance, and High Availability. Monitoring MySQL replication provides you with the visibility and control needed to manage complex database environments effectively. It allows you to proactively address issues, optimize performance, and ensure that the replication setup meets your data management requirements.

To go to the Replication section, go to the MySQL database details page and click Replication on the left pane under Resources.

In the Replication section, you can monitor replication configuration information and metrics on the following tabs:

• Summary tab: Displays the various replication configuration parameters and metrics for the MySQL server.
  • Configuration: In this section, the following replication configuration parameters are displayed:
    • Instance: The MySQL server in the replication setup.
    • Inbound: The number of replication channels where the MySQL server receives data from another server. This indicates whether the MySQL server is configured to receive data from another server, and is a replica.
    • Instance type: The role of the MySQL server in the replication process, such as source, replica, or primary group member.
    • Server ID: A unique identifier assigned to each MySQL server, critical for the replication process to distinguish between different servers.
    • Server UUID: The universally unique identifier (UUID) for the MySQL server, providing another layer of identification for replication and ensuring server uniqueness.
    • Outbound: The number of replication channels where the MySQL server sends data. This indicates whether the MySQL server is configured to send data to other servers, and is the source.
    • Read only: Indicates whether the server is in read-only mode, which restricts data modification operations:
      • ON: The MySQL server is configured as read_only.
      • SUPER: The MySQL server is configured as super_read_only.
      • OFF: The MySQL server is neither read_only nor super_read_only.
    • Binary logging: Indicates whether binary logging is enabled. This is a feature that logs data-modifying SQL statements, and is essential for replication as it provides a record of changes to be sent to replicas.
    • Log format: The format of the binary log, such as STATEMENT or ROW, which determines how changes are logged and replicated.
    • Global transaction ID mode: Indicates whether GTID-based replication is enabled. Global transaction ID (GTID) provides a unique identifier for each transaction, enabling more reliable and consistent replication.
  • Status: In this section, the following replication details are displayed:
    • Active connections: The number of currently active connections to the MySQL server.
    • Statement count: The total number of SQL statements executed on the MySQL server.
    • Fetch state: The current status of the fetch operations. Indicates whether the replica successfully retrieved data from the source.
    • Apply state: The current status of the apply operations. Indicates if the changes are successfully applied to the replica.
    • High Availability member state: The current status of the MySQL server within the replication group. For information on the various statuses, see Group Replication Server States.
    • Avg statement latency: The average time taken to execute SQL statements.
    • Global transaction identifiers executed: The GTIDs of all the transactions executed on the MySQL server or explicitly set as purged.
    • Time behind: The number of seconds this replica lags behind the source in processing the transactions from the source binary log.
  • Statistics: In this section, the following replication metric charts are displayed:
    • Active connections: Displays the number of currently active connections to the MySQL server.
    • Statement count: Displays the total number of SQL statements executed on the MySQL server.
    • Avg statement latency (seconds): Displays the average time taken to execute SQL statements.
• High Availability tab: Displays the High Availability and disaster recovery configuration parameters, group replication metrics for the MySQL server, and group replication members. This tab is displayed when monitoring replication types that utilize Group Replication or are part of an InnoDB Cluster.
  • Configuration: In this section, the following group replication High Availability parameters are displayed:
    • Group name: A unique identifier that distinguishes the replication group to which the MySQL server belongs. Each MySQL server in the group has the same group name, which ensures that MySQL servers replicate only with their intended peers.
    • Flow control state: Indicates whether flow control is currently active in the group replication setup, which helps maintain group stability and consistency by preventing slower members from accumulating excessive transaction backlogs:
      • DISABLED: Flow control is turned off and no throttling occurs.
      • QUOTA: Flow control is active and the group regulates the transaction flow based on predefined thresholds.
    • Group auto increment: The interval between successive values for auto-incremented columns for transactions that execute on the MySQL server.
    • Deployment mode: Indicates the deployment mode of the group:
      • Single primary: Only one primary member that accepts write operations.
      • Multi primary: All members can accept write operations concurrently.
  • Status: In this section, the following group replication details are displayed:
    • View ID: The current view identifier for the group.
    • Member state: The current status of the MySQL server within the replication group. For information on the various statuses, see Group Replication Server States.
    • Transactions in GTID_EXECUTED: The number of transactions that were replicated within the group.
  • Statistics: In this section, the following metric charts are displayed:
    • Queued transactions: Displays the number of transactions in the queue pending conflict detection checks.
    • Rows validating: Displays the number of rows currently undergoing validation to detect conflicts during transaction certification.
    • Transactions checked: Displays the number of transactions that have been checked for conflicts across the group.
    • Conflicts detected: Displays the number of transactions that failed conflict detection.
  • Group replication members: In this section, the MySQL servers in the replication group are listed, along with the following details:
    • Host: The network address (host name or IP address) of the member server.
    • Port: The port number on which the member server is listening for connections.
    • State: The current status of the member server.
    • Role: The role of the member server.
    • Server UUID: The UUID of the member server.
• Inbound tab: Displays inbound replication channel information and metrics. This tab is displayed if the MySQL server is configured as a replica in the replication process.
  • Relay log metrics: In this section, the following relay log metric charts, which are aggregated for all inbound replication channels, are displayed:
    • Space usage (bytes): Displays the amount of disk space used by the relay log files on the replica.
      Note
      
      If the monitoring user does not have the REPLICATION CLIENT privilege, data is not displayed in this metric chart.
    • File I/O read (bytes per second): Displays the rate at which data is read from the relay log files.
    • File I/O written (bytes per second): Displays the rate at which data is written to the relay log files.
    • File I/O latency (microseconds): Displays the delay between when data is read from and written to the relay log files.
  • Health: In this section, the following details regarding the health of the Receiver and Applier components is displayed:
    • Receiver is responsible for establishing and maintaining the connection to the source.
      • Status: The current state of the receiver, which indicates whether it's currently running and functioning correctly.
      • Error Number: The numeric code of the last error encountered by the receiver.
      • Error Message: The message corresponding to the error number.
    • Applier is responsible for executing the events retrieved by the receiver and applying them to the replica.
      • Status: The current state of the applier, which indicates whether it's currently running and functioning correctly.
      • Error Number: The numeric code of the last error encountered by the applier.
      • Error Message: The message corresponding to the error number.
  • Configuration: In this section, the following inbound replication channel parameters are displayed:
    • Source is the upstream MySQL server from which data is being replicated.
      • Host: The host name or IP address of the source.
      • Port: The port number on the source that the replica should connect to for replication.
      • Server UUID: The UUID of the source.
      • ID: The server ID of the source.
    • Replica is the current MySQL server.
      • Server UUID: The UUID of the replica.
      • ID: The server ID of the replica.
    • Apply settings influence how the replica applies the transactions received from the source.
      • Delay: The configured number of seconds that this replica must lag behind the source on this channel.
      • Workers: The configured number of applier threads for executing replication transactions in parallel.
      • Global transaction ID handling: Indicates whether the channel assigns GTIDs to replicated transactions that do not have one:
        • OFF: No GTIDs are assigned.
        • LOCAL: A GTID is assigned that includes this replica's UUID.
        • <UUID>: A GTID is assigned that includes a manually set UUID.
    • Filters control which data is replicated from the source to the replica. They can be configured to include or exclude specific databases, tables, or other objects.
  • Statistics: In this section, the following inbound replication channel details are displayed:
    • Relay log storage space used: The total disk space consumed by the relay log files pertaining to this channel.
    • Transactions received: The number of transactions the replica has received from the source server.
    • Apply delay: The time the current transaction took between being committed on the source and being applied on the replica.
    • Busy workers: The number of replication worker threads currently active in applying transactions through this channel to the replica.
• Outbound tab: Displays information pertaining to the replicas of the MySQL server. This tab is displayed if the MySQL server is configured as a source in the replication process.
  • Configuration: In this section, the replicas of the current MySQL server are listed, along with the following details:
    • Host: The host name of the replica, as specified on the replica using the --report-host option.
    • Port: The port on which the replica is listening, as specified on the replica with the --report-port option.
    • Server ID: The server ID of the replica.
    • Server UUID: The UUID of the replica.
• Binary log tab: Displays an overview of the binary log configuration parameters, details, and metric charts for the MySQL server.
  • Configuration: In this section, the following binary log configuration parameters are displayed:
    • Enabled: Indicates whether binary logging is active on the server.
    • Log format: Indicates the format in which changes are recorded in the binary log:
      • STATEMENT: Logs the SQL statements that modify data.
      • ROW: Logs the actual data changes at the row level.
      • MIXED: Switches between statement-based and row-based replication, depending on the nature of the statement.
    • Log compression: Indicates whether compression is enabled and applied to the binary log to reduce disk space usage and network bandwidth.
  • Status: In this section, the following binary log details are displayed:
    • Binary log name: The current binary log file being used by the MySQL server.
    • Binary log position: The current position within the active binary log file where the MySQL server is writing.
    • Log compression percentage: The percentage of compression achieved for the binary log files, if Log compression is enabled.
  • Statistics: In this section, the following binary log metric charts are displayed:
    • Storage space usage (bytes): Displays the total disk space used by the binary log files.
    • I/O read (bytes per second): Displays the rate at which data is read from the binary log files.
    • I/O written (bytes per second): Displays the rate at which data is written to the binary log files.
    • I/O latency (microseconds): Displays the delay when reading or writing to the binary log files.