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 ofMYSQL_BINLOG_FILE
to be persisted toPERSISTENT_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 |
+-----------+-----------------+----------+-----------+---------------+-----------------+