Cong LiIn today's data-driven business environment, the performance and reliability of databases are crucial to the success of enterprises. The GBase 8s SSC cluster architecture optimizes network interactions to significantly enhance performance and availability. This article, the first of a two-part series, focuses on an overview of network interaction information and network throughput calculation in GBase 8s SSC clusters.
In the GBase 8s SSC cluster, the primary node only needs to transmit network heartbeats and the current logical log position information to the secondary node. The SSC secondary node only needs to read the logical log from the shared disk based on the latest LSN number from the primary node. This reduces network information transmission and minimizes the impact of network factors such as latency on synchronization performance. Consequently, network transmission between nodes in the SSC cluster is much less compared to logical log writing, thereby minimizing the impact of network performance on the overall performance of the SSC cluster.
In an SSC cluster with only one secondary node, assuming a TPCC test performance of 1 million tpmc at 400 concurrency, the theoretical maximum network throughput between the primary and secondary nodes is about 3.5 MB/s, with the primary node sending PPS at 16666.7 packets/s. This scenario ignores other primary-secondary message interactions, and the actual network throughput in real test scenarios is higher than this theoretical value.
Additionally, in scenarios where the SSC secondary node supports updates, assuming the TPCC test only includes neworder business and is directly executed on the SSC secondary node, if the TPCC performance reaches 1 million tpmc, the network throughput is 248.9 MB/s, with the SSC secondary node sending PPS at 400,000 packets/s.
1. SSC Cluster Architecture and Working Principle
The GBase 8s SSC cluster is a shared storage cluster that allows multiple database instances to simultaneously access and operate on the same database. It features high availability, high performance, load balancing, and supports automatic failover and automatic rejoining of failed nodes.
1.1 SSC Cluster Architecture
1.2 SSC Cluster Working Principle
Unlike HDR and RSS clusters, the SSC cluster does not need to transmit logical log files between primary and secondary nodes. The primary node only needs to send the current logical log position to the secondary node, which can then retrieve the log from the shared storage based on the received LSN. The detailed working principle is as follows:
- The primary node completes data updates and sends the current LSN (Log Sequence Number) to the SSC secondary node.
- The SSC secondary node receives the LSN from the primary node and reads the updated logical log from the disk.
- The SSC secondary node redoes the logical log to update the data in memory.
- The SSC secondary node returns an LSN ACK.
Additionally, like other cluster types, the SSC cluster requires regular heartbeat messages between primary and secondary nodes to maintain cluster status.
2. Optimization of Network Interaction
No-Load Scenarios
In the absence of business operations, the primary node sends network heartbeats to the secondary node every second. During business operations, when the logical log buffer is flushed to disk, the primary node sends the current LSN to the secondary node. The message sequence between primary and secondary nodes is as follows:
Heartbeat packets consist of MACH11_PING and IamAlive message types, with lengths of 24 bytes and 16 bytes, respectively. The SSC secondary node replies with ACK packets, including MACH11_PINGACK and IamAlive message types.
During business operations, the primary node sends data packets consisting of logLPG and MACH11_PING message types. The SSC secondary node replies with data packets consisting of logLSN and MACH11_PINGACK message types. The lengths of various messages are as follows:
| Message Type | Message Length (Bytes) |
|---|---|
| MACH11_PING | 24 |
| MACH11_PINGACK | 16 |
| IamAlive | 16 |
| logLPG | 28 |
| logLSN | 24 |
The composition of each data packet is shown below:
SMX Header contains 20 bytes.
In no-business scenarios, the lengths of various network packets are as follows:
- Primary Node Heartbeat Packet: 20 + 24 + 16 = 60 bytes, plus Ethernet, IP, and TCP headers totaling at least 54 bytes (14 + 20 + 20), resulting in a total length of 114 bytes.
- SSC Secondary Node ACK Packet: 54 + 16 + 16 = 86 bytes.
In business scenarios, the lengths of various network packets are as follows:
- LSN Network Packet: 54 + 20 + 28 + 24 = 126 bytes.
- SSC Secondary Node LSN ACK Packet: 54 + 24 + 16 = 94 bytes.
3. SSC Secondary Node Update Support
When the SSC cluster UPDATABLE_SECONDARY is set to a non-zero value, the SSC secondary node supports update operations. The detailed process is as follows:
- The SSC secondary node server receives the update operation, performs syntax and semantic parsing, and converts the syntax tree to CB, including generating the execution plan.
- The SSC secondary node synchronizes the execution plan and related information to the primary node.
- The primary node receives the message from the SSC secondary node and performs the update operation.
- The primary node completes the data update and synchronizes the result to the SSC secondary node.
For example, in a DML operation, the message sequence between the primary and secondary nodes is as follows:
In a DML operation, the lengths of various messages are as follows:
| Message Type | Message Composition | Message Length (Bytes) |
|---|---|---|
| ProxyWriteBeginWork | Vector[0]: Message Header Vector[1]: Begin Content |
176 |
| ProxyWriteInsert | Vector[0]: Message Header Vector[1]: DML Header Vector[2]: Row Image Vector[3]: col bitmap buffer Length Vector[4]: col bitmap buffer Content Vector[5]: Isolation Level (optional, sent once per transaction) |
108 + Row Length + Column Bitmap Buffer Length |
| ProxyWriteDelete | Vector[0]: Message Header Vector[1]: DML Header Vector[2]: Row Image Vector[3]: col bitmap buffer Length Vector[4]: col bitmap buffer Content Vector[5]: Isolation Level (optional, sent once per transaction) |
108 + Row Length + Column Bitmap Buffer Length |
| ProxyWriteUpdate | Vector[0]: Message Header Vector[1]: DML Header Vector[2]: Before Row Image Vector[3]: After Row Image Vector[4]: col bitmap buffer Length Vector[5]: col bitmap buffer Content Vector[6]: Isolation Level (optional, sent once per transaction) |
108 + Row Length * 2 + Column Bitmap Buffer Length |
| ProxyWriteSync | Vector[0]: Message Header Vector[1]: Sync Content (optional, added when primary responds to SSC secondary) |
28 (SSC to Primary), 68 (Primary to SSC) |
| ProxyWriteFlush2LSN | Vector[0]: Message Header Vector[1]: LSN |
36 |
| ProxyWriteCommit | Vector[0]: Message Header | 28 |
Each data packet includes an SMX Header of 20 bytes, as shown in Figure 5. A single Insert SQL transaction requires three network packets, assuming the table has three columns and a row length of 40 (column bitmap buffer length is 4). The details of the three sets of network packets are as follows:
First Set of Network Packet Information:
- SSC Secondary Node to Primary Node: Network packet composed of ProxyWriteBeginWork, ProxyWriteInsert, and ProxyWriteSync messages, with a length of 54 + 20 + 176 + (108 + 40 + 4) + 28 = 430 bytes.
- Primary Node Response: Network packet composed of ProxyWriteSync message, with a length of 54 + 20 + 68 = 142 bytes.
Second Set of Network Packet Information:
- SSC Secondary Node to Primary Node: Network packet composed of ProxyWriteCommit message, with a length of 54 + 20 + 28 = 102 bytes.
- Primary Node Response: Network packet composed of ProxyWriteSync message, with a length of 54 + 20 + 68 = 142 bytes.
Third Set of Network Packet Information:
- SSC Secondary Node to Primary Node: Network packet composed of ProxyWriteBeginWork, ProxyWriteFlush2LSN, and ProxyWriteCommit messages, with a length of 54 + 20 + 176 + 36 + 28 = 314 bytes.
- Primary Node Response: Network packet composed of ProxyWriteSync message, with a length of 54 + 20 + 68 = 142 bytes.
The network interaction mechanism of GBase 8s SSC cluster is key to its high performance. By reducing unnecessary data transmission, the SSC cluster can achieve fast business processing and fault recovery while maintaining data consistency.
