Merge pull request #352 from percona/pxc-5243-8.4

PXC-5243 [DOCS] - PXC missing documentation about streaming replicati…

Author: patrickbirch

docs/gcache-record-set-cache-difference.md

@@ -24,8 +24,7 @@ then the storage is switched from Heap to Page
 All these limits are non-configurable,
 but having a memory-page size greater than 4MB per transaction
 can cause things to stall due to memory pressure,
-so this limit is reasonable. This is another
-limitation to address when Galera supports large transaction.
+so this limit is reasonable. For large or long-running transactions that exceed these caches, use [streaming replication](streaming-replication.md).
 
 The same long-running transaction will also generate binlog data
 that also appends to out-write-set on commit (`HeapStore->FileStore`).

docs/glossary.md

@@ -22,6 +22,10 @@ This property guarantees that all updates of a transaction occur in the database
 Normal replication path for cluster members. Can be encrypted (not by
 default) and unicast or multicast (unicast by default). Runs on tcp port 4567 by default.
 
+## Certification
+
+Process by which Galera validates that a transaction's changes do not conflict with changes already committed on other cluster nodes. For details, see [Certification in Percona XtraDB Cluster](certification.md).
+
 ## Consistency
 
 This property guarantees that each transaction that modifies the database takes it from one consistent state to another. Consistency is implied with [Isolation](#isolation).
@@ -38,6 +42,10 @@ The node elected to provide a state transfer (SST or IST).
 
 Once a transaction is committed, it will remain so and is resistant to a server exit.
 
+## Flow control
+
+Mechanism that pauses write-set replication when a node's receive queue exceeds configured thresholds. Flow control throttles the cluster to let slow nodes catch up. Monitor flow control with the status variables in [Index of wsrep status variables](wsrep-status-index.md#flow-control-variables).
+
 ## Foreign Key
 
 A referential constraint between two tables. Example: A purchase order in the purchase_orders table must have been made by a customer that exists in the customers table.
@@ -149,6 +157,10 @@ A majority (> 50%) of nodes. In the event of a network partition, only the clus
 
 Split brain occurs when two parts of a computer cluster are disconnected, each part believing that the other is no longer running. This problem can lead to data inconsistency.
 
+## Streaming replication
+
+A Galera 4 feature that divides large or long-running transactions into smaller fragments. Galera certifies and replicates each fragment while the transaction remains open. Enable streaming replication at the session level with [`wsrep_trx_fragment_unit`](wsrep-system-index.md#wsrep_trx_fragment_unit) and [`wsrep_trx_fragment_size`](wsrep-system-index.md#wsrep_trx_fragment_size). For details, see [Streaming replication for large transactions](streaming-replication.md).
+
 ## SST
 
 State Snapshot Transfer is the full copy of data from one node to another.  It's used when a new node joins the cluster, it has to transfer data from an existing node.
@@ -168,6 +180,10 @@ A [`Storage Engine`](#storage-engine) is a piece of software that implements the
 
 A tech preview item can be a feature, a variable, or a value within a variable. The term designates that the item is not yet ready for production use and is not included in support by SLA. A tech preview item is included in a release so that users can provide feedback. The item is either updated and released as [general availability(GA)](#general-availability-ga) or removed if not useful. The item’s functionality can change from tech preview to GA.
 
+## Write-set
+
+Binary log representation of the rows a transaction modifies. Galera replicates write-sets between cluster nodes for [certification](#certification) and application. Write-set caching during long transactions is described in [Understand GCache and Record-Set cache](gcache-record-set-cache-difference.md).
+
 ## UUID
 
 Universally Unique IDentifier which uniquely identifies the state and the sequence of changes node undergoes. 128-bit UUID is a classic DCE UUID Version 1 (based on current time and MAC address). Although in theory this UUID could be generated based on the real MAC-address, in the Galera it is always (without exception) based on the generated pseudo-random addresses ("locally administered" bit in the node address (in the UUID structure) is  always equal to unity).

docs/index-contents.md

@@ -55,6 +55,7 @@
   - [Security basics](security-index.md)
   - [Set up a testing environment with ProxySQL](virtual-sandbox.md)
   - [Set up Galera arbitrator](garbd-howto.md)
+  - [Streaming replication for large transactions](streaming-replication.md)
   - [State snapshot transfer](state-snapshot-transfer.md)
   - [State Snapshot Transfer (SST) Method using Clone plugin](clone-sst.md)
   - [Telemetry on Percona XtraDB Cluster](telemetry.md)

docs/limitation.md

@@ -26,6 +26,8 @@ The following limitations apply to Percona XtraDB Cluster:
 
     `LOAD DATA INFILE` processing will commit every 10 000 rows. So large transactions due to `LOAD DATA` will be split into a series of small transactions.
 
+    For transactions that exceed these limits or cause replication lag and flow control, use [streaming replication](streaming-replication.md) (available in Galera 4) instead of raising the limits globally.
+
 * Transaction issuing `COMMIT` may still be aborted at that stage.
 
     Due to cluster-level optimistic concurrency control, there can be two transactions writing to the same rows and committing on separate Percona XtraDB Cluster nodes, and only one of them can successfully commit. The failing one will be aborted. For cluster-level aborts, Percona XtraDB Cluster returns a deadlock error code: