|
1 | 1 | # High availability
|
2 | 2 |
|
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. |
11 | 4 |
|
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: |
14 | 6 |
|
15 | 7 |
|
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. | |
40 | 12 |
|
41 | 13 | You can monitor the current state of a node using the following command:
|
42 | 14 |
|
43 |
| -```sql |
44 |
| -SHOW STATUS LIKE 'wsrep_local_state_comment'; |
| 15 | +```{.bash data-prompt="mysql>"} |
| 16 | +mysql> SHOW STATUS LIKE 'wsrep_local_state_comment'; |
45 | 17 | ```
|
46 | 18 |
|
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