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.SNAPSHOT_PERSISTENT_SNAPSHOT_INDEX;
SELECT * FROM INFORMATION_SCHEMA.SNAPSHOT_INNODB_PERSISTENT_SNAPSHOT_INDEX;
SELECT * FROM INFORMATION_SCHEMA.SNAPSHOT_INNODB_PERSISTENT_SNAPSHOTS;
SELECT * FROM INFORMATION_SCHEMA.SNAPSHOT_SMARTENGINE_PERSISTENT_SNAPSHOT_INDEX;
SELECT * FROM INFORMATION_SCHEMA.SNAPSHOT_SMARTENGINE_PERSISTENT_SNAPSHOTS;
SELECT * FROM INFORMATION_SCHEMA.SNAPSHOT_SMARTENGINE_EXTENT_SNAPSHOTS;
SELECT * FROM INFORMATION_SCHEMA.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 |
+-------------------------------------------------------------------------------------------+---------------------+------+
| sysbench/binlog/binlog.000001.00000000000000000002.0000000251 | 2024-09-11 08:13:38 | 251 |
| sysbench/binlog/binlog.000001.00000000000000000003.0000000333 | 2024-09-11 08:14:59 | 82 |
| sysbench/binlog/binlog.000001.00000000000000000003.0000001566 | 2024-09-11 08:16:01 | 1233 |
| sysbench/binlog/binlog.000001.00000000000000000003.0000002137 | 2024-09-11 08:16:07 | 571 |
| sysbench/binlog/binlog.000001.00000000000000000004.0000003015 | 2024-09-11 08:18:46 | 878 |
| sysbench/binlog/binlog.000001.00000000000000000004.0000004261 | 2024-09-11 08:18:57 | 1246 |
| sysbench/binlog/binlog.000001.00000000000000000004.0000004309 | 2024-09-11 08:39:25 | 48 |
| sysbench/binlog/binlog.000002.00000000000000000004.0000000251 | 2024-09-11 08:39:28 | 251 |
| sysbench/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 |
+-----------------------------------------------+---------------+----------------+---------------+--------------------------+

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

SNAPSHOT_PERSISTENT_SNAPSHOT_INDEX

In WeSQL, each snapshot consists of three parts: InnoDB snapshot data, SmartEngine snapshot data, and the binlog position at which the snapshot was taken. During the process of generating a 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 snapshot was taken has been persisted to object storage through binlog archiving.

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

SNAPSHOT_PERSISTENT_SNAPSHOT_INDEX has these colums:

  • CREATED_TS The creation timestamp of snapshot object.

  • MYSQL_INNODB_SNAPSHOT_NAME

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

  • SMARTENGINE_SNAPSHOT_NAME

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

  • BINLOG_NAME

    The persisted binlog file required to restore the InnoDB and SmartEngine data of the snapshot to a consistent database 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 snapshot to a consistent database state. The snapshot can only be in a consistent database 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 SNAPSHOT_SMARTENGINE_EXTENT_SNAPSHOTS.

mysql> DESC INFORMATION_SCHEMA.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.SNAPSHOT_PERSISTENT_SNAPSHOT_INDEX\G
*************************** 1. row ***************************
CREATED_TS: 2024-09-11 02:58:51
MYSQL_INNODB_SNAPSHOT_NAME: sysbench/snapshot/main/innodb_000004.tar
SMARTENGINE_SNAPSHOT_NAME: sysbench/snapshot/main/smartengine_000004.tar
BINLOG_NAME: binlog.000001
BINLOG_POS: 16903
RAFT_INDEX: 8
SMARTENGINE_SNAPSHOT: 1726023531647

SNAPSHOT_INNODB_PERSISTENT_SNAPSHOT_INDEX

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 SNAPSHOT_INNODB_PERSISTENT_SNAPSHOTS, but not in 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.SNAPSHOT_INNODB_PERSISTENT_SNAPSHOT_INDEX;
+-----------------------+--------------+------+-----+---------+-------+
| Field | Type | Null | Key | Default | Extra |
+-----------------------+--------------+------+-----+---------+-------+
| INNODB_SNAPSHOT_NAME | varchar(512) | NO | | | |
+-----------------------+--------------+------+-----+---------+-------+

Example:

mysql> SELECT * FROM INFORMATION_SCHEMA.SNAPSHOT_INNODB_PERSISTENT_SNAPSHOT_INDEX;
+------------------------------------------------------------------------------------+
| INNODB_SNAPSHOT_NAME |
+------------------------------------------------------------------------------------+
| sysbench/snapshot/main/innodb_000008.tar |
| sysbench/snapshot/main/innodb_000009.tar |
+------------------------------------------------------------------------------------+

SNAPSHOT_INNODB_PERSISTENT_SNAPSHOTS

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.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.SNAPSHOT_INNODB_PERSISTENT_SNAPSHOTS;
+------------------------------------------------------------------------------------+---------------------+----------+
| INNODB_SNAPSHOT_KEY | LAST_MODIFIED | SIZE |
+------------------------------------------------------------------------------------+---------------------+----------+
| sysbench/snapshot/main/innodb_000008.tar | 2024-09-11 08:39:32 | 76810240 |
| sysbench/snapshot/main/innodb_000009.tar | 2024-09-11 08:45:16 | 76810240 |
+------------------------------------------------------------------------------------+---------------------+----------+

SNAPSHOT_SMARTENGINE_PERSISTENT_SNAPSHOT_INDEX

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 SNAPSHOT_SMARTENGINE_PERSISTENT_SNAPSHOTS, but not in 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.SNAPSHOT_SMARTENGINE_PERSISTENT_SNAPSHOT_INDEX;
+---------------------------+--------------+------+-----+---------+-------+
| Field | Type | Null | Key | Default | Extra |
+---------------------------+--------------+------+-----+---------+-------+
| SMARTENGINE_SNAPSHOT_NAME | varchar(512) | NO | | | |
+---------------------------+--------------+------+-----+---------+-------+

Example:

mysql> SELECT * FROM INFORMATION_SCHEMA.SNAPSHOT_SMARTENGINE_PERSISTENT_SNAPSHOT_INDEX;
+--------------------------------------------------------------------------------+
| SMARTENGINE_SNAPSHOT_NAME |
+--------------------------------------------------------------------------------+
| sysbench/snapshot/main/smartengine_000008.tar |
| sysbench/snapshot/main/smartengine_000009.tar |
+--------------------------------------------------------------------------------+

SNAPSHOT_SMARTENGINE_PERSISTENT_SNAPSHOTS

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.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.SNAPSHOT_SMARTENGINE_PERSISTENT_SNAPSHOTS;
+--------------------------------------------------------------------------------+---------------------+---------+
| SMARTENGINE_SNAPSHOT_KEY | LAST_MODIFIED | SIZE |
+--------------------------------------------------------------------------------+---------------------+---------+
| sysbench/snapshot/main/smartengine_000008.tar | 2024-09-11 08:40:08 | 2201600 |
| sysbench/snapshot/main/smartengine_000009.tar | 2024-09-11 08:45:49 | 2222080 |
+--------------------------------------------------------------------------------+---------------------+---------+

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.SNAPSHOT_SMARTENGINE_EXTENT_SNAPSHOTS displays a list of the SmartEngine snapshot ID.

  • SMARTENGINE_SNAPSHOT

    The SmartEngine snapshot ID.

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

Example:

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

SNAPSHOT_PERSISTENT_TASK_INFO

INFORMATION_SCHEMA.SNAPSHOT_PERSISTENT_TASK_INFO displays the status information of WeSQL snapshot persistence background task.

  • PERSISTENT_PROGRESS

    The progress of the currently executing snapshot.

  • RAFT_TERM

    The raft term during which the snapshot persistence occurred.

  • START_TIMESTAMP

    The start timestamp of the currently executing snapshot.

  • END_TIMESTAMP

    The end timestamp of the currently executing snapshot.

  • INNODB_SNAPSHOT_NAME

    The InnoDB snapshot name of the currently executing snapshot.

  • INNODB_SNAPSHOT_DURATION

    The duration during which the InnoDB snapshot is generated in the currently executing snapshot.

  • INNODB_SNAPSHOT_PERSISTENT_DURATION

    The duration during which the InnoDB snapshot is persisted in the currently executing snapshot.

  • SMARTENGINE_SNAPSHOT_NAME

    The SmartEngine snapshot name of the currently executing snapshot.

  • SMARTENGINE_SNAPSHOT_ID

    The SmartEngine extent snapshot of the currently executing snapshot.

  • SMARTENGINE_SNAPSHOT_DURATION

    The duration during which the SmartEngine snapshot is generated in the currently executing snapshot.

  • SMARTENGINE_SNAPSHOT_PERSISTENT_DURATION

    The duration during which the SmartEngine snapshot is persisted in the currently executing snapshot.

  • MYSQL_BINLOG_FILE

    The mysql binlog file required to restore the InnoDB and SmartEngine data of the snapshot to a consistent database state in the currently executing snapshot.

  • PERSISTENT_BINLOG_FILE

    The persisted binlog file required to restore the InnoDB and SmartEngine data of the snapshot to a consistent database state in the currently executing snapshot.

  • RAFT_INDEX

    The binlog position of the PERSISTENT_BINLOG_FILE required to restore the InnoDB and SmartEngine data of the snapshot to a consistent database state.

  • WAIT_BINLOG_PERSISTENT_DURATION

    The duration of waiting for the RAFT_INDEX position of MYSQL_BINLOG_FILE to be persisted to PERSISTENT_BINLOG_FILE in the currently executing snapshot.

mysql> DESC information_schema.SNAPSHOT_PERSISTENT_TASK_INFO;
+------------------------------------------+--------------+------+-----+---------+-------+
| Field | Type | Null | Key | Default | Extra |
+------------------------------------------+--------------+------+-----+---------+-------+
| PERSISTENT_PROGRESS | varchar(512) | NO | | | |
| RAFT_TERM | bigint | NO | | | |
| START_TIMESTAMP | varchar(512) | NO | | | |
| END_TIMESTAMP | varchar(512) | NO | | | |
| INNODB_SNAPSHOT_NAME | varchar(512) | NO | | | |
| INNODB_SNAPSHOT_DURATION | bigint | NO | | | |
| INNODB_SNAPSHOT_PERSISTENT_DURATION | bigint | NO | | | |
| SMARTENGINE_SNAPSHOT_NAME | varchar(512) | NO | | | |
| SMARTENGINE_SNAPSHOT_ID | bigint | NO | | | |
| SMARTENGINE_SNAPSHOT_DURATION | bigint | NO | | | |
| SMARTENGINE_SNAPSHOT_PERSISTENT_DURATION | bigint | NO | | | |
| MYSQL_BINLOG_FILE | varchar(512) | NO | | | |
| MYSQL_BINLOG_OFFSET | bigint | NO | | | |
| PERSISTENT_BINLOG_FILE | varchar(512) | NO | | | |
| RAFT_INDEX | bigint | NO | | | |
| WAIT_BINLOG_PERSISTENT_DURATION | bigint | NO | | | |
+------------------------------------------+--------------+------+-----+---------+-------+

Example:

mysql> SELECT * FROM INFORMATION_SCHEMA.SNAPSHOT_PERSISTENT_TASK_INFO\G
*************************** 1. row ***************************
PERSISTENT_PROGRESS: END
RAFT_TERM: 4
START_TIMESTAMP: 2024-09-22 13:33:42
END_TIMESTAMP: 2024-09-22 13:34:13
INNODB_SNAPSHOT_NAME: innodb_000067
INNODB_SNAPSHOT_DURATION: 1
INNODB_SNAPSHOT_PERSISTENT_DURATION: 1
SMARTENGINE_SNAPSHOT_NAME: smartengine_000067
SMARTENGINE_SNAPSHOT_ID: 1727012022927
SMARTENGINE_SNAPSHOT_DURATION: 0
SMARTENGINE_SNAPSHOT_PERSISTENT_DURATION: 29
MYSQL_BINLOG_FILE: ./master-bin.000437
MYSQL_BINLOG_OFFSET: 2512785
PERSISTENT_BINLOG_FILE: binlog.000437
RAFT_INDEX: 2104366
WAIT_BINLOG_PERSISTENT_DURATION: 0

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 raft. For a Leader node, its COMMIT_INDEX represents the latest raft 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 raft 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 raft 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 |
+-----------+-----------------+----------+-----------+---------------+-----------------+