Skip to main content

Observability

Objects on Object Storage​

WeSQL provides a set of system views to inspect the status information of objects that have been persisted to object storage.

Examples:

SELECT * FROM INFORMATION_SCHEMA.BINLOG_PERSISTENT_SLICE_INDEX;
SELECT * FROM INFORMATION_SCHEMA.BINLOG_PERSISTENT_SLICES;
SELECT * FROM INFORMATION_SCHEMA.CONSISTENT_SNAPSHOT_PERSISTENT_SNAPSHOT_INDEX;
SELECT * FROM INFORMATION_SCHEMA.CONSISTENT_SNAPSHOT_INNODB_PERSISTENT_SNAPSHOT_INDEX;
SELECT * FROM INFORMATION_SCHEMA.CONSISTENT_SNAPSHOT_INNODB_PERSISTENT_SNAPSHOTS;
SELECT * FROM INFORMATION_SCHEMA.CONSISTENT_SNAPSHOT_SMARTENGINE_PERSISTENT_SNAPSHOT_INDEX;
SELECT * FROM INFORMATION_SCHEMA.CONSISTENT_SNAPSHOT_SMARTENGINE_PERSISTENT_SNAPSHOTS;
SELECT * FROM INFORMATION_SCHEMA.CONSISTENT_SNAPSHOT_SMARTENGINE_EXTENT_SNAPSHOTS;
SELECT * FROM INFORMATION_SCHEMA.CONSISTENT_SNAPSHOT_SMARTENGINE_EXTENT_SNAPSHOTS;

BINLOG_PERSISTENT_SLICES​

In WeSQL, a binlog file is a logical concept from the MySQL server layer. In MySQL, a binlog file is a physical file (e.g. a file in some POSIX file system). However, in WeSQL, a single binlog file is stored as multiple objects in object storage.

Each binlog file is divided into multiple objects (where each object represents a slice) when persisted to object storage.

This binlog slicing approach allows the binlog data to be uploaded in smaller chunks (for example, 4MB) instead of uploading the entire binlog file at once. This can improve upload efficiency and also makes managing and cleaning up binlogs in object storage easier.

For example, as shown below, binlog.000001 is split into multiple slices, each slice being a separate object stored in object storage. The naming convention of a slice in S3 is as follows:

{binlog file name}.{raft term}.{log end position}

binlog.000001.00000000000000000002.0000000251
binlog.000001.00000000000000000003.0000000333
binlog.000001.00000000000000000003.0000001566
binlog.000001.00000000000000000003.0000002137
binlog.000001.00000000000000000004.0000004261

  • {binlog file name} represents the binlog file to which the current slice object belongs, named similarly to a MySQL binlog.

  • {raft term} indicates the Raft term during which the slice was created. Slices from the same binlog file could have been created across different Raft terms.

  • {log end position} represents the ending position of the slice within the binlog file. The {log end position} of the last slice is always the size of the entire binlog file. With these slices, the entire binlog file can be reconstructed or recovered.

BINLOG_PERSISTENT_SLICES displays a list of binlog objects that have been persisted to object storage, showing each slice object as it appears in object storage.

  • LOG_SLICE_KEY

    The full object key of binlog slice object in object storage.

  • LAST_MODIFIED

    The last modified timestamp of binlog slice object in object storage.

  • SIZE

    The size of binlog slice object in object storage.

mysql> DESC INFORMATION_SCHEMA.BINLOG_PERSISTENT_SLICES;
+---------------+--------------+------+-----+---------+-------+
| Field         | Type         | Null | Key | Default | Extra |
+---------------+--------------+------+-----+---------+-------+
| LOG_SLICE_KEY | varchar(512) | NO   |     |         |       |
| LAST_MODIFIED | timestamp    | NO   |     |         |       |
| SIZE          | bigint       | NO   |     |         |       |
+---------------+--------------+------+-----+---------+-------+

Example:

mysql> SELECT * FROM INFORMATION_SCHEMA.BINLOG_PERSISTENT_SLICES;
+-------------------------------------------------------------------------------------------+---------------------+------+
| LOG_SLICE_KEY                                                                             | LAST_MODIFIED       | SIZE |
+-------------------------------------------------------------------------------------------+---------------------+------+
| FD2D88FB-7994-4318-AD3F-2E37ADF52DBC/binlog/binlog.000001.00000000000000000002.0000000251 | 2024-09-11 08:13:38 |  251 |
| FD2D88FB-7994-4318-AD3F-2E37ADF52DBC/binlog/binlog.000001.00000000000000000003.0000000333 | 2024-09-11 08:14:59 |   82 |
| FD2D88FB-7994-4318-AD3F-2E37ADF52DBC/binlog/binlog.000001.00000000000000000003.0000001566 | 2024-09-11 08:16:01 | 1233 |
| FD2D88FB-7994-4318-AD3F-2E37ADF52DBC/binlog/binlog.000001.00000000000000000003.0000002137 | 2024-09-11 08:16:07 |  571 |
| FD2D88FB-7994-4318-AD3F-2E37ADF52DBC/binlog/binlog.000001.00000000000000000004.0000003015 | 2024-09-11 08:18:46 |  878 |
| FD2D88FB-7994-4318-AD3F-2E37ADF52DBC/binlog/binlog.000001.00000000000000000004.0000004261 | 2024-09-11 08:18:57 | 1246 |
| FD2D88FB-7994-4318-AD3F-2E37ADF52DBC/binlog/binlog.000001.00000000000000000004.0000004309 | 2024-09-11 08:39:25 |   48 |
| FD2D88FB-7994-4318-AD3F-2E37ADF52DBC/binlog/binlog.000002.00000000000000000004.0000000251 | 2024-09-11 08:39:28 |  251 |
| FD2D88FB-7994-4318-AD3F-2E37ADF52DBC/binlog/binlog.000002.00000000000000000004.0000002397 | 2024-09-11 08:39:32 | 2146 |
+-------------------------------------------------------------------------------------------+---------------------+------+

BINLOG_PERSISTENT_SLICE_INDEX​

BINLOG_PERSISTENT_SLICE_INDEX displays a list of binlog files that have been successfully persisted to object storage and recorded in the persisted binlog index. Only binlog files present in this persisted binlog index are considered successfully atomically persisted and visible. If a binlog file exists in object storage but is not listed in this persisted binlog index, it is considered invalid and subject to cleanup. Therefore, it is possible that binlog slice objects are shown in BINLOG_PERSISTENT_SLICES, but not in BINLOG_PERSISTENT_SLICE_INDEX.

BINLOG_PERSISTENT_SLICE_INDEX has these colums:

  • LOG_SLICE_NAME

    The binlog slice that has been successfully persisted to object storage and recorded in the persisted binlog index.

  • LOG_NAME

    The binlog file containing the binlog slice.

  • RAFT_TERM

    The raft term during which the binlog slice was persisted to object storage.

  • SLICE_END_POS

    The the ending position of the binlog slice within the binlog file.

  • PREVIOUS_RAFT_INDEX

    The previous raft index of the binlog file.

mysql> DESC INFORMATION_SCHEMA.BINLOG_PERSISTENT_SLICE_INDEX;
+--------------------------+--------------+------+-----+---------+-------+
| Field                    | Type         | Null | Key | Default | Extra |
+--------------------------+--------------+------+-----+---------+-------+
| LOG_SLICE_NAME           | varchar(512) | NO   |     |         |       |
| LOG_NAME                 | varchar(512) | NO   |     |         |       |
| RAFT_TERM                | bigint       | NO   |     |         |       |
| SLICE_END_POS            | bigint       | NO   |     |         |       |
| PREVIOUS_RAFT_INDEX      | bigint       | NO   |     |         |       |
+--------------------------+--------------+------+-----+---------+-------+

Example:

mysql> SELECT * FROM INFORMATION_SCHEMA.BINLOG_PERSISTENT_SLICE_INDEX;
+-----------------------------------------------+---------------+----------------+---------------+--------------------------+
| LOG_SLICE_NAME                                | LOG_NAME      | RAFT_TERM      | SLICE_END_POS | PREVIOUS_RAFT_INDEX      |
+-----------------------------------------------+---------------+----------------+---------------+--------------------------+
| binlog.000001.00000000000000000002.0000000251 | binlog.000001 |              2 |           251 |                        0 |
| binlog.000001.00000000000000000003.0000000333 | binlog.000001 |              3 |           333 |                        0 |
| binlog.000001.00000000000000000003.0000001566 | binlog.000001 |              3 |          1566 |                        0 |
| binlog.000001.00000000000000000003.0000002137 | binlog.000001 |              3 |          2137 |                        0 |
| binlog.000001.00000000000000000004.0000003015 | binlog.000001 |              4 |          3015 |                        0 |
| binlog.000001.00000000000000000004.0000004261 | binlog.000001 |              4 |          4261 |                        0 |
| binlog.000001.00000000000000000004.0000004309 | binlog.000001 |              4 |          4309 |                        0 |
| binlog.000002.00000000000000000004.0000000251 | binlog.000002 |              4 |           251 |                        7 |
| binlog.000002.00000000000000000004.0000002397 | binlog.000002 |              4 |          2397 |                        7 |
+-----------------------------------------------+---------------+----------------+---------------+--------------------------+

CONSISTENT_SNAPSHOT_PERSISTENT_SNAPSHOT_INDEX​

In WeSQL, each consistent snapshot consists of three parts: InnoDB snapshot data, SmartEngine snapshot data, and the binlog position at which the consistent snapshot was taken. During the process of generating a consistent snapshot, a SmartEngine snapshot is first created and persisted to object storage. Then, an InnoDB snapshot is generated and persisted to object storage. Finally, it is confirmed that the binlog position at which the consistent snapshot was taken has been persisted to object storage through binlog archiving.

CONSISTENT_SNAPSHOT_PERSISTENT_SNAPSHOT_INDEX displays a list of persistent consistent snapshot objects stored in object storage. The data is read from the consistent snapshot index object, with each row representing a consistent snapshot.

CONSISTENT_SNAPSHOT_PERSISTENT_SNAPSHOT_INDEX has these colums:

  • CREATED_TS The creation timestamp of consistent snapshot object.

  • MYSQL_INNODB_SNAPSHOT_NAME

    The SmartEngine snapshot data included in the consistent snapshot. For more information, see description in CONSISTENT_SNAPSHOT_SMARTENGINE_PERSISTENT_SNAPSHOT_INDEX.

  • SMARTENGINE_SNAPSHOT_NAME

    The SmartEngine snapshot data included in the consistent snapshot. For more information, see description in CONSISTENT_SNAPSHOT_INNODB_PERSISTENT_SNAPSHOT_INDEX.

  • BINLOG_NAME

    The persisted binlog file required to restore the InnoDB and SmartEngine data of the consistent snapshot to a consistent state. For more information, see description in BINLOG_PERSISTENT_SLICE_INDEX.

  • RAFT_INDEX

    The binlog position of the binlog_archive_name required to restore the InnoDB and SmartEngine data of the consistent snapshot to a consistent state. The consistent snapshot can only be in a consistent state when both the InnoDB and SmartEngine data have been restored to the binlog position corresponding to this raft index.

  • SMARTENGINE_SNAPSHOT

    The SmartEngine snapshot data refers to the SmartEngine persisted extent data snapshot ID. For more information, see description in CONSISTENT_SNAPSHOT_SMARTENGINE_EXTENT_SNAPSHOTS.

mysql> DESC INFORMATION_SCHEMA.CONSISTENT_SNAPSHOT_PERSISTENT_SNAPSHOT_INDEX;
+---------------------------+--------------+------+-----+---------+-------+
| Field                     | Type         | Null | Key | Default | Extra |
+---------------------------+--------------+------+-----+---------+-------+
| CREATED_TS                | varchar(512) | NO   |     |         |       |
| MYSQL_INNODB_SNAPSHOT_NAME| varchar(512) | NO   |     |         |       |
| SMARTENGINE_SNAPSHOT_NAME | varchar(512) | NO   |     |         |       |
| BINLOG_NAME               | varchar(512) | NO   |     |         |       |
| BINLOG_POS                | bigint       | NO   |     |         |       |
| RAFT_INDEX                | bigint       | NO   |     |         |       |
| SMARTENGINE_SNAPSHOT      | bigint       | NO   |     |         |       |
+---------------------------+--------------+------+-----+---------+-------+

Example:

mysql> SELECT * FROM INFORMATION_SCHEMA.CONSISTENT_SNAPSHOT_PERSISTENT_SNAPSHOT_INDEX\G
*************************** 1. row ***************************
                CREATED_TS: 2024-09-11 02:58:51
MYSQL_INNODB_SNAPSHOT_NAME: FD2D88FB-7994-4318-AD3F-2E37ADF52DBC/consistent_snapshot/innodb_archive_000004.tar
 SMARTENGINE_SNAPSHOT_NAME: FD2D88FB-7994-4318-AD3F-2E37ADF52DBC/consistent_snapshot/se_archive_000004.tar
               BINLOG_NAME: binlog.000001
                BINLOG_POS: 16903
                RAFT_INDEX: 8
      SMARTENGINE_SNAPSHOT: 1726023531647

CONSISTENT_SNAPSHOT_INNODB_PERSISTENT_SNAPSHOT_INDEX​

CONSISTENT_SNAPSHOT_INNODB_PERSISTENT_SNAPSHOT_INDEX displays a list of InnoDB snapshot that have been successfully persisted to object storage and recorded in the persisted innodb index. Only InnoDB snapshot present in this persisted innodb index are considered successfully atomically persisted and visible. If a InnoDB snapshot exists in object storage but is not listed in this persisted innodb index, it is considered invalid and subject to cleanup. Therefore, it is possible that InnoDB snapshot objects are shown in CONSISTENT_SNAPSHOT_INNODB_PERSISTENT_SNAPSHOTS, but not in CONSISTENT_SNAPSHOT_INNODB_PERSISTENT_SNAPSHOT_INDEX.

  • INNODB_SNAPSHOT_NAME

    The full object key of the InnoDB snapshot object in the object storage and recorded in the persisted innodb index.

mysql> DESC INFORMATION_SCHEMA.CONSISTENT_SNAPSHOT_INNODB_PERSISTENT_SNAPSHOT_INDEX;
+-----------------------+--------------+------+-----+---------+-------+
| Field                 | Type         | Null | Key | Default | Extra |
+-----------------------+--------------+------+-----+---------+-------+
| INNODB_SNAPSHOT_NAME  | varchar(512) | NO   |     |         |       |
+-----------------------+--------------+------+-----+---------+-------+

Example:

mysql> SELECT * FROM INFORMATION_SCHEMA.CONSISTENT_SNAPSHOT_INNODB_PERSISTENT_SNAPSHOT_INDEX;
+------------------------------------------------------------------------------------+
| INNODB_SNAPSHOT_NAME                                                                       |
+------------------------------------------------------------------------------------+
| FD2D88FB-7994-4318-AD3F-2E37ADF52DBC/consistent_snapshot/innodb_archive_000008.tar |
| FD2D88FB-7994-4318-AD3F-2E37ADF52DBC/consistent_snapshot/innodb_archive_000009.tar |
+------------------------------------------------------------------------------------+

CONSISTENT_SNAPSHOT_INNODB_PERSISTENT_SNAPSHOTS​

CONSISTENT_SNAPSHOT_INNODB_PERSISTENT_SNAPSHOTS displays a list of persistent InnoDB snapshot objects stored in object storage.

  • INNODB_SNAPSHOT_KEY

    The full object key of the InnoDB snapshot object in the object storage.

  • LAST_MODIFIED

    The last modified timestamp of InnoDB snapshot object in object storage.

  • SIZE

    The size of InnoDB snapshot object in object storage.

mysql> DESC INFORMATION_SCHEMA.CONSISTENT_SNAPSHOT_INNODB_PERSISTENT_SNAPSHOTS;
+----------------------+--------------+------+-----+---------+-------+
| Field                | Type         | Null | Key | Default | Extra |
+----------------------+--------------+------+-----+---------+-------+
| INNODB_SNAPSHOT_KEY  | varchar(512) | NO   |     |         |       |
| LAST_MODIFIED        | timestamp    | NO   |     |         |       |
| SIZE                 | bigint       | NO   |     |         |       |
+----------------------+--------------+------+-----+---------+-------+

Example:

mysql> SELECT * FROM INFORMATION_SCHEMA.CONSISTENT_SNAPSHOT_INNODB_PERSISTENT_SNAPSHOTS;
+------------------------------------------------------------------------------------+---------------------+----------+
| INNODB_SNAPSHOT_KEY                                                                | LAST_MODIFIED       | SIZE     |
+------------------------------------------------------------------------------------+---------------------+----------+
| FD2D88FB-7994-4318-AD3F-2E37ADF52DBC/consistent_snapshot/innodb_archive_000008.tar | 2024-09-11 08:39:32 | 76810240 |
| FD2D88FB-7994-4318-AD3F-2E37ADF52DBC/consistent_snapshot/innodb_archive_000009.tar | 2024-09-11 08:45:16 | 76810240 |
+------------------------------------------------------------------------------------+---------------------+----------+

CONSISTENT_SNAPSHOT_SMARTENGINE_PERSISTENT_SNAPSHOT_INDEX​

CONSISTENT_SNAPSHOT_SMARTENGINE_PERSISTENT_SNAPSHOT_INDEX displays a list of SmartEngine snapshot that have been successfully persisted to object storage and recorded in the persisted smartengine index. Only SmartEngine snapshot present in this persisted smartengine index are considered successfully atomically persisted and visible. If a SmartEngine snapshot exists in object storage but is not listed in this persisted smartengine index, it is considered invalid and subject to cleanup. Therefore, it is possible that SmartEngine snapshot objects are shown in CONSISTENT_SNAPSHOT_SMARTENGINE_PERSISTENT_SNAPSHOTS, but not in CONSISTENT_SNAPSHOT_SMARTENGINE_PERSISTENT_SNAPSHOT_INDEX.

  • SMARTENGINE_SNAPSHOT_NAME

    The full object key of the SmartEngine snapshot object in the object storage and recorded in the persisted smartengine index.

mysql> DESC INFORMATION_SCHEMA.CONSISTENT_SNAPSHOT_SMARTENGINE_PERSISTENT_SNAPSHOT_INDEX;
+---------------------------+--------------+------+-----+---------+-------+
| Field                     | Type         | Null | Key | Default | Extra |
+---------------------------+--------------+------+-----+---------+-------+
| SMARTENGINE_SNAPSHOT_NAME | varchar(512) | NO   |     |         |       |
+---------------------------+--------------+------+-----+---------+-------+

Example:

mysql> SELECT * FROM INFORMATION_SCHEMA.CONSISTENT_SNAPSHOT_SMARTENGINE_PERSISTENT_SNAPSHOT_INDEX;
+--------------------------------------------------------------------------------+
| SMARTENGINE_SNAPSHOT_NAME                                                      |
+--------------------------------------------------------------------------------+
| FD2D88FB-7994-4318-AD3F-2E37ADF52DBC/consistent_snapshot/se_archive_000008.tar |
| FD2D88FB-7994-4318-AD3F-2E37ADF52DBC/consistent_snapshot/se_archive_000009.tar |
+--------------------------------------------------------------------------------+

CONSISTENT_SNAPSHOT_SMARTENGINE_PERSISTENT_SNAPSHOTS​

CONSISTENT_SNAPSHOT_SMARTENGINE_PERSISTENT_SNAPSHOTS displays a list of persistent SmartEngine snapshot objects stored in object storage.

  • SMARTENGINE_SNAPSHOT_KEY

    The full object key of the SmartEngine snapshot object in the object storage.

  • LAST_MODIFIED

    The last modified timestamp of SmartEngine snapshot object in object storage.

  • SIZE

    The size of SmartEngine snapshot object in object storage.

mysql> DESC INFORMATION_SCHEMA.CONSISTENT_SNAPSHOT_SMARTENGINE_PERSISTENT_SNAPSHOTS;
+---------------------------+--------------+------+-----+---------+-------+
| Field                     | Type         | Null | Key | Default | Extra |
+---------------------------+--------------+------+-----+---------+-------+
| SMARTENGINE_SNAPSHOT_KEY  | varchar(512) | NO   |     |         |       |
| LAST_MODIFIED             | timestamp    | NO   |     |         |       |
| SIZE                      | bigint       | NO   |     |         |       |
+---------------------------+--------------+------+-----+---------+-------+

Example:

mysql> SELECT * FROM INFORMATION_SCHEMA.CONSISTENT_SNAPSHOT_SMARTENGINE_PERSISTENT_SNAPSHOTS;
+--------------------------------------------------------------------------------+---------------------+---------+
| SMARTENGINE_SNAPSHOT_KEY                                                       | LAST_MODIFIED       | SIZE    |
+--------------------------------------------------------------------------------+---------------------+---------+
| FD2D88FB-7994-4318-AD3F-2E37ADF52DBC/consistent_snapshot/se_archive_000008.tar | 2024-09-11 08:40:08 | 2201600 |
| FD2D88FB-7994-4318-AD3F-2E37ADF52DBC/consistent_snapshot/se_archive_000009.tar | 2024-09-11 08:45:49 | 2222080 |
+--------------------------------------------------------------------------------+---------------------+---------+

CONSISTENT_SNAPSHOT_SMARTENGINE_EXTENT_SNAPSHOTS​

In WeSQL, SmartEngine's tables are physically composed of multiple extent object. Each new extent is created, and is persisted as a separate object in object storage with the extent ID as the key. Every time a new SmartEngine snapshot is generated, a snapshot ID is created, and the snapshot ID along with all extent IDs are recorded in the CHECKPOINT file in a key-value format (this CHECKPOINT file also records all historical snapshots of SmartEngine). For each SmartEngine snapshot, the extent IDs corresponding to the snapshot ID can be directly accessed from object storage. During extent reclamation, SmartEngine determines if extents can be safely reclaimed by checking all the snapshot IDs referenced in the CHECKPOINT file.

INFORMATION_SCHEMA.CONSISTENT_SNAPSHOT_SMARTENGINE_EXTENT_SNAPSHOTS displays a list of the SmartEngine snapshot ID.

  • SMARTENGINE_SNAPSHOT

    The SmartEngine snapshot ID.

mysql> DESC INFORMATION_SCHEMA.CONSISTENT_SNAPSHOT_SMARTENGINE_EXTENT_SNAPSHOTS;
+----------------------+--------+------+-----+---------+-------+
| Field                | Type   | Null | Key | Default | Extra |
+----------------------+--------+------+-----+---------+-------+
| SMARTENGINE_SNAPSHOT | bigint | NO   |     |         |       |
+----------------------+--------+------+-----+---------+-------+

Example:

mysql> SELECT * FROM INFORMATION_SCHEMA.CONSISTENT_SNAPSHOT_SMARTENGINE_EXTENT_SNAPSHOTS;
+----------------------+
| SMARTENGINE_SNAPSHOT |
+----------------------+
|        1726043971161 |
|        1726044314636 |
+----------------------+

BINLOG_PERSISTENT_TASK_INFO​

INFORMATION_SCHEMA.BINLOG_PERSISTENT_TASK_INFO displays the status information of WeSQL binlog persistence background task.

  • LAST_RAFT_INDEX

    The latest raft index of the binlog that has been persisted. In WeSQL, each binlog event has a corresponding raft index, which can uniquely identify the binlog position.

  • LAST_RAFT_TERM

    The raft term during which the binlog persistence occurred.

  • LAST_MYSQL_BINLOG

    The latest MySQL binlog file that has been persisted.

  • LAST_MYSQL_BINLOG_PERSISTENT_POS

    The latest position of the lastest persisted MySQL local binlog.

  • LAST_MYSQL_BINLOG_READ_POS

    The latest read position of the lastest persisted MySQL local binlog.

  • LAST_PERSISTENT_BINLOG

    The latest binlog object in object storage.

  • LAST_PERSISTENT_BINLOG_POS

    The latest position of the latest binlog object in object storage.

  • LAST_PERSISTENT_BINLOG_WRITE_POS

    The latest position of the local cache for latest binlog persistence. The binlog events from last_persistent_binlog_pos to last_persistent_binlog_write_pos represents the binlog events that is about to be persisted.

mysql> DESC INFORMATION_SCHEMA.BINLOG_PERSISTENT_TASK_INFO;
+----------------------------------+--------------+------+-----+---------+-------+
| Field                            | Type         | Null | Key | Default | Extra |
+----------------------------------+--------------+------+-----+---------+-------+
| LAST_RAFT_INDEX                  | bigint       | NO   |     |         |       |
| LAST_RAFT_TERM                   | bigint       | NO   |     |         |       |
| LAST_MYSQL_BINLOG                | varchar(512) | NO   |     |         |       |
| LAST_MYSQL_BINLOG_PERSISTENT_POS | bigint       | NO   |     |         |       |
| LAST_MYSQL_BINLOG_READ_POS       | bigint       | NO   |     |         |       |
| LAST_PERSISTENT_BINLOG           | varchar(512) | NO   |     |         |       |
| LAST_PERSISTENT_BINLOG_POS       | bigint       | NO   |     |         |       |
| LAST_PERSISTENT_BINLOG_WRITE_POS | bigint       | NO   |     |         |       |
+----------------------------------+--------------+------+-----+---------+-------+

Example:

mysql> SELECT * FROM INFORMATION_SCHEMA.BINLOG_PERSISTENT_TASK_INFO\G
*************************** 1. row ***************************
                 LAST_RAFT_INDEX: 9
                  LAST_RAFT_TERM: 4
               LAST_MYSQL_BINLOG: ./master-bin.000002
LAST_MYSQL_BINLOG_PERSISTENT_POS: 4993
      LAST_MYSQL_BINLOG_READ_POS: 4993
          LAST_PERSISTENT_BINLOG: binlog.000002
      LAST_PERSISTENT_BINLOG_POS: 4993
LAST_PERSISTENT_BINLOG_WRITE_POS: 4993

Membership in the Raft Group​

The membership status information of the Raft Group can be viewed using the following system views:

SELECT * FROM INFORMATION_SCHEMA.WESQL_CLUSTER_GLOBAL;
SELECT * FROM INFORMATION_SCHEMA.WESQL_CLUSTER_LOCAL;
SELECT * FROM INFORMATION_SCHEMA.WESQL_CLUSTER_HEALTH;
SELECT * FROM mysql.consensus_info;
SELECT * FROM mysql.consensus_applier_info;
SELECT * FROM mysql.consensus_applier_worker;
SELECT * FROM mysql.slave_master_info;
SELECT * FROM mysql.slave_relay_log_info;
SELECT * FROM mysql.slave_worker_info;

WESQL_CLUSTER_GLOBAL​

WESQL_CLUSTER_GLOBAL Display information about the role, commit index, applied index, etc., of all nodes in the WeSQL Raft Group. This view is only valid when displayed on a Leader role node.

  • SERVER_ID

    Identifies the unique number of each node, generated when the node instance is created.

  • IP_PORT

    Describes the IP and PORT information of each node, specified by cluster_info when the node instance is created.

  • MATCH_INDEX

    The log synchronization write position for each node. For the Leader, it is the log write position; for other nodes, it is the log synchronization position.

  • NEXT_INDEX

    The log position that the Leader node needs to synchronize with other nodes next.

  • ROLE

    The role each node represents in the raft protocol. The supported role types include Leader, Candidate, Follower, Learner, and No Role.

  • HAS_VOTED

    Indicates whether each node has already voted in the raft algorithm protocol.

  • FORCE_SYNC

    Whether the current node uses force synchronization for log syncing. This can be dynamically modified on the Leader node using dbms_consensus.configure_follower.

  • ELECTION_WEIGHT

    The election weight of the current node, ranging from 1 to 9. The higher the value, the higher the probability of being elected as Leader. This can be dynamically modified on the Leader node using dbms_consensus.configure_follower.

  • LEARNER_SOURCE

    If the current node has the Learner role, this represents the source node's SERVER_ID for that Learner.

  • APPLIED_INDEX

    The log replay position for Follower or Learner nodes.

  • PIPELINING

    Whether the logs are synchronized in pipelining mode.

  • SEND_APPLIED

    Whether the source server of a Learner only synchronizes logs that have already been applied. FALSE means that only committed logs are synchronized to the downstream Learner. Therefore, this column is only valid for Learner nodes.

mysql> DESC INFORMATION_SCHEMA.WESQL_CLUSTER_GLOBAL;
+-----------------+--------------+------+-----+---------+-------+
| Field           | Type         | Null | Key | Default | Extra |
+-----------------+--------------+------+-----+---------+-------+
| SERVER_ID       | int          | NO   |     |         |       |
| IP_PORT         | varchar(261) | NO   |     |         |       |
| MATCH_INDEX     | bigint       | NO   |     |         |       |
| NEXT_INDEX      | bigint       | NO   |     |         |       |
| ROLE            | varchar(10)  | NO   |     |         |       |
| HAS_VOTED       | varchar(3)   | NO   |     |         |       |
| FORCE_SYNC      | varchar(3)   | NO   |     |         |       |
| ELECTION_WEIGHT | bigint       | NO   |     |         |       |
| LEARNER_SOURCE  | bigint       | NO   |     |         |       |
| APPLIED_INDEX   | bigint       | NO   |     |         |       |
| PIPELINING      | varchar(3)   | NO   |     |         |       |
| SEND_APPLIED    | varchar(3)   | NO   |     |         |       |
+-----------------+--------------+------+-----+---------+-------+
mysql> SELECT * FROM INFORMATION_SCHEMA.WESQL_CLUSTER_GLOBAL\G
*************************** 1. row ***************************
      SERVER_ID: 1
        IP_PORT: 127.0.0.1:13006
    MATCH_INDEX: 1
     NEXT_INDEX: 0
           ROLE: Leader
      HAS_VOTED: Yes
     FORCE_SYNC: No
ELECTION_WEIGHT: 5
 LEARNER_SOURCE: 0
  APPLIED_INDEX: 0
     PIPELINING: No
   SEND_APPLIED: No
*************************** 2. row ***************************
      SERVER_ID: 2
        IP_PORT: 127.0.0.1:13007
    MATCH_INDEX: 1
     NEXT_INDEX: 2
           ROLE: Follower
      HAS_VOTED: Yes
     FORCE_SYNC: No
ELECTION_WEIGHT: 5
 LEARNER_SOURCE: 0
  APPLIED_INDEX: 1
     PIPELINING: Yes
   SEND_APPLIED: No
*************************** 3. row ***************************
      SERVER_ID: 3
        IP_PORT: 127.0.0.1:13008
    MATCH_INDEX: 1
     NEXT_INDEX: 2
           ROLE: Follower
      HAS_VOTED: No
     FORCE_SYNC: No
ELECTION_WEIGHT: 5
 LEARNER_SOURCE: 0
  APPLIED_INDEX: 1
     PIPELINING: Yes
   SEND_APPLIED: No

WESQL_CLUSTER_LOCAL​

WESQL_CLUSTER_LOCAL displays the role, commit index, applied index, and other information of the current node in the WeSQL Raft Group.

  • SERVER_ID

    The unique identifier of the current node, generated when the node instance is created.

  • CURRENT_TERM

    The current term of the logs for this node.

  • CURRENT_LEADER

    Information about the current Leader node of the cluster.

  • COMMIT_INDEX

    The commit index that the current node has reached for consensus. For a Leader node, its COMMIT_INDEX represents the latest consensus point in the cluster.

  • LAST_LOG_TERM

    The term of the last synchronized log.

  • LAST_LOG_INDEX

    The log synchronization write position of the current node. For a Leader node, it is equivalent to WESQL_CLUSTER_GLOBAL.MATCH_INDEX.

  • ROLE

    The role the current node represents in the consensus protocol. The supported role types include Leader, Candidate, Follower, Learner, and No Role. This is equivalent to WESQL_CLUSTER_GLOBAL.ROLE.

  • VOTED_FOR

    The SERVER_ID of the node that the current node voted for during the election process when acting as a high-availability role (Leader or Follower). A value of 0 indicates no vote has been cast (e.g., Learner nodes do not vote). For new nodes joining an existing cluster with an active Leader, if no re-election has occurred after joining, VOTED_FOR will also be 0.

  • LAST_APPLY_INDEX

    If the current node is a Follower or Learner, this shows the log replay position.

  • SERVER_READY_FOR_RW

    Displays “Yes” if the current node is ready to generate and send binlog; displays “No” if the node can only replay binlog or is a Logger node.

  • INSTANCE_TYPE

    Indicates whether the current node is a Logger node. “Log” means it is a Logger node, while “Normal” means it is a regular data node.

mysql> DESC INFORMATION_SCHEMA.WESQL_CLUSTER_LOCAL;
+---------------------+--------------+------+-----+---------+-------+
| Field               | Type         | Null | Key | Default | Extra |
+---------------------+--------------+------+-----+---------+-------+
| SERVER_ID           | int          | NO   |     |         |       |
| CURRENT_TERM        | bigint       | NO   |     |         |       |
| CURRENT_LEADER      | varchar(261) | NO   |     |         |       |
| COMMIT_INDEX        | bigint       | NO   |     |         |       |
| LAST_LOG_TERM       | bigint       | NO   |     |         |       |
| LAST_LOG_INDEX      | bigint       | NO   |     |         |       |
| ROLE                | varchar(10)  | NO   |     |         |       |
| VOTED_FOR           | int          | NO   |     |         |       |
| LAST_APPLY_INDEX    | bigint       | NO   |     |         |       |
| SERVER_READY_FOR_RW | varchar(3)   | NO   |     |         |       |
| INSTANCE_TYPE       | varchar(10)  | NO   |     |         |       |
+---------------------+--------------+------+-----+---------+-------+
mysql> SELECT * FROM INFORMATION_SCHEMA.WESQL_CLUSTER_LOCAL\G
*************************** 1. row ***************************
          SERVER_ID: 1
       CURRENT_TERM: 111
     CURRENT_LEADER: 127.0.0.1:13006
       COMMIT_INDEX: 1
      LAST_LOG_TERM: 111
     LAST_LOG_INDEX: 1
               ROLE: Leader
          VOTED_FOR: 1
   LAST_APPLY_INDEX: 0
SERVER_READY_FOR_RW: Yes
      INSTANCE_TYPE: Normal

WESQL_CLUSTER_HEALTH​

WESQL_CLUSTER_HEALTH displays the health status information of all nodes in the WeSQL Raft Group.

  • SERVER_ID

    The unique identifier of the current node, generated when the node instance is created.

  • IP_PORT

    The IP and PORT information of each node, specified by cluster_info when the node instance is created. This is equivalent to WESQL_CLUSTER_GLOBAL.IP_PORT.

  • ROLE

    The role the node represents in the consensus protocol. The supported role types include Leader, Candidate, Follower, Learner, and No Role. This is equivalent to WESQL_CLUSTER_GLOBAL.ROLE.

  • CONNECTED

    Indicates whether the node is able to establish a connection.

  • LOG_DELAY_NUM

    The number of log synchronization delays for the node.

  • APPLY_DELAY_NUM

    The number of log replay delays for the node.

mysql> DESC INFORMATION_SCHEMA.WESQL_CLUSTER_HEALTH;
+-----------------+--------------+------+-----+---------+-------+
| Field           | Type         | Null | Key | Default | Extra |
+-----------------+--------------+------+-----+---------+-------+
| SERVER_ID       | int          | NO   |     |         |       |
| IP_PORT         | varchar(261) | NO   |     |         |       |
| ROLE            | varchar(10)  | NO   |     |         |       |
| CONNECTED       | varchar(3)   | NO   |     |         |       |
| LOG_DELAY_NUM   | bigint       | NO   |     |         |       |
| APPLY_DELAY_NUM | bigint       | NO   |     |         |       |
+-----------------+--------------+------+-----+---------+-------+
mysql> SELECT * FROM INFORMATION_SCHEMA.WESQL_CLUSTER_HEALTH;
+-----------+-----------------+----------+-----------+---------------+-----------------+
| SERVER_ID | IP_PORT         | ROLE     | CONNECTED | LOG_DELAY_NUM | APPLY_DELAY_NUM |
+-----------+-----------------+----------+-----------+---------------+-----------------+
|         1 | 127.0.0.1:13006 | Leader   | YES       |             0 |               0 |
|         2 | 127.0.0.1:13007 | Follower | YES       |             0 |               0 |
|         3 | 127.0.0.1:13008 | Follower | YES       |             0 |               0 |
+-----------+-----------------+----------+-----------+---------------+-----------------+