Skip to content

Commit fa67f7f

Browse files
authored
Merge pull request #241 from percona/pxc-4692
PXC-4692 [DOCS] - Update High Availability 8.4
2 parents 7a087f1 + 707d0f9 commit fa67f7f

File tree

1 file changed

+19
-38
lines changed

1 file changed

+19
-38
lines changed

docs/high-availability.md

Lines changed: 19 additions & 38 deletions
Original file line numberDiff line numberDiff line change
@@ -1,48 +1,29 @@
11
# High availability
22

3-
In a basic setup with 3 nodes, Percona XtraDB Cluster will continue to function
4-
if you take any of the nodes down.
5-
At any point in time, you can shut down any node to perform maintenance
6-
or make configuration changes.
7-
Even in unplanned situations
8-
(like a node crashing or if it becomes unavailable over the network),
9-
the Percona XtraDB Cluster will continue to work
10-
and you’ll be able to run queries on working nodes.
3+
Percona XtraDB Cluster will continue to function in a basic setup with three nodes if you take any of the nodes down. At any point, you can shut down any node to perform maintenance or make configuration changes. Even in unplanned situations such as a node crash or a network failure that makes a node unavailable, Percona XtraDB Cluster continues to operate, and you can run queries on the remaining active nodes.
114

12-
If there were changes to data while a node was down,
13-
there are two options that the node may use when it joins the cluster again:
5+
If data changed while a node was down, the node has two options when rejoining the cluster:
146

157

16-
* **State Snapshot Transfer** (SST) is when all data is copied
17-
from one node to another.
18-
19-
SST is usually used when a new node joins the cluster
20-
and receives all data from an existing node.
21-
Percona XtraDB Cluster uses **xtrabackup** for SST.
22-
23-
SST using `xtrabackup` does not require the `READ LOCK` command
24-
for the entire syncing process, only for syncing [.frm](glossary.md#frm) files (the same as with a regular backup).
25-
26-
27-
* Incremental State Transfer (IST) is when only incremental changes
28-
are copied from one node to another.
29-
30-
Even without locking your cluster in read-only state, SST may be intrusive
31-
and disrupt normal operation of your services.
32-
IST lets you avoid that.
33-
If a node goes down for a short period of time,
34-
it can fetch only those changes that happened while it was down.
35-
IST is implemeted using a caching mechanism on nodes.
36-
Each node contains a cache, ring-buffer (the size is configurable)
37-
of last N changes, and the node is able to transfer part of this cache.
38-
Obviously, IST can be done only if the amount of changes needed to transfer
39-
is less than N. If it exceeds N, then the joining node has to perform SST.
8+
| Option | Description |
9+
|----------------------------|-------------|
10+
| State Snapshot Transfer (SST) | SST copies all data from one node to another. The cluster typically uses it when a new node joins and needs to receive the full dataset from an existing node. Percona XtraDB Cluster performs SST using xtrabackup. During this process, xtrabackup does not lock the database for the entire sync; it uses the READ LOCK command only when syncing .frm files, just like in a regular backup. |
11+
| Incremental State Transfer (IST) | IST transfers only incremental changes from one node to another. It avoids the disruption of SST by letting a briefly offline node fetch only the changes made during its downtime without setting the cluster to read-only. Each node implements IST using a caching mechanism. It maintains a ring buffer of a configurable size that stores the last N changes. If the node finds the needed changes within the buffer, it transfers them through IST. If the changes exceed the buffer size, the node falls back to using SST. |
4012

4113
You can monitor the current state of a node using the following command:
4214

43-
```sql
44-
SHOW STATUS LIKE 'wsrep_local_state_comment';
15+
```{.bash data-prompt="mysql>"}
16+
mysql> SHOW STATUS LIKE 'wsrep_local_state_comment';
4517
```
4618

47-
When a node is in `Synced (6)` state, it is part of the cluster
48-
and ready to handle traffic.
19+
??? example "Expected output"
20+
21+
```{.text .no-copy}
22+
+---------------------------+--------+
23+
| Variable_name | Value |
24+
+---------------------------+--------+
25+
| wsrep_local_state_comment | Synced |
26+
+---------------------------+--------+
27+
```
28+
29+
When a node reaches the `Synced` state, the node has completed the process of synchronizing its data with the rest of the cluster. At this point, the cluster considers the node to be fully integrated and operational. The node can now begin processing client requests, participating in read and write operations, and contributing to the overall workload distribution within the cluster.

0 commit comments

Comments
 (0)