Galera Cluster 4 has been released for MySQL 8, providing new features like streaming replication, improved foreign key support, and group commit. Streaming replication allows nodes to process writesets greater than 2GB by replicating transactions in small fragments before commit. Galera Cluster is developed by Codership and provides multi-master replication for high availability with no single point of failure. Future releases will include additional features from the Galera Cluster roadmap.

1. Colin Charles, colin.charles@galeracluster.com | 4 June 2020
Galera Cluster 4 for MySQL 8

2. Agenda
• Codership
• What is Galera replication?
• Galera Cluster 4 for MySQL 8
• Comparison of the offerings of Galera Cluster 4
• Conclusion

3. Codership
• Codership are the original makers and engineers of Galera Cluster, a multi-
master, virtually synchronous replication solution for the MySQL ecosystem
• If you use Percona XtraDB Cluster (PXC) or MariaDB Galera Cluster, you
directly benefit from the work done by the team at Codership
• Remember that beyond engineering, you may also purchase 24/7 support,
training, consulting and a whole lot more!

4. Codership
• The developers and experts of Galera Cluster
• Established in 2007, 3 founders, all engineers
• Seppo Jaakola, CEO, Teemu Ollakka, CTO, Alex Yurchenko, architect
• Services business model, producing 100% open source software
• Thousands of users in various industries: e-commerce, betting/gambling,
telecoms, banking, insurance, gaming, healthcare, media, marketing,
advertising, travel, education, software as a service, PaaS, IaaS, etc.

5. What is Galera replication?
• A generic replication plugin for database servers
• Uses the replication API to interact with a DBMS (via the wsrep API project,
fully open source on GitHub)
• wsrep == writeset replication
• The database and Galera plugin must have the same wsrep API version

8. Galera Cluster
• MariaDB Server (which comes with Galera Cluster) has over 12 million downloads as of
March 2017; Percona XtraDB Cluster (PXC) has over 1.3 million downloads; more from
galeracluster.com; we can’t count distributions!
• Cloud platforms recommend Galera Cluster usage for High Availability — e.g. OpenStack
• Thousands of users in various industries (e-commerce, gaming, telecom, banking,
insurance, healthcare, SaaS, IaaS, PaaS, etc) have trusted Galera Cluster over a decade.
• MySQL Community Award: Application of the Year 2014
• Included in many mainstream Linux/BSD distributions (Ubuntu, Debian, Fedora, RHEL8,
openSUSE, FreeBSD, etc.)

9. Galera Cluster is all about multi-master replication
• Can be described as virtually synchronous replication
• High Availability with no data loss, and consistent data across all nodes — no Single Point of Failure (SPoF)
• Quorum based failure handling
• Optimistic concurrency control
• 100% multi-master cluster (all nodes are equal in terms of having the data, so no lagging secondaries, 24/7 availability, etc.)
• This is a core feature of the product by design, has automatic transaction conflict detection and management, and your
application can issue any transaction to any Galera Cluster node. Works well in WAN/Clouds
• Parallel replication
• You do not need automatic failovers via a framework, no need to designate single nodes for writes and the rest for reads,
configuration is simple, easier handling of scheduled downtime

10. Galera Cluster optimised for the cloud
• Optimised network protocol as packets are only exchanged over the WAN at transaction
commit time
• Topology-aware replication, so each transaction is sent to the data centre only once
• Detection and automatic eviction of unreliable nodes
• eviction if due to network flaps or node failure, will not be able to rejoin without manual
intervention
• Split brain recovery/management
• Traffic encryption (key in the cloud)

11. Branch Variants

12. Galera Replication Versions
• There have been many major releases (1,2,3,4)
• Current production head is at 3.29 for Galera 3, and 4.5 for Galera 4
• There have been many wsrep API versions (1..25)
• Current major version is wsrep API 26 which corresponds with Galera 4
(wsrep API 25 corresponds with Galera 3)
• There are wsrep API changes that require you to perform a rolling upgrade

13. Galera 4 & MySQL 8
• MySQL 8.0.19 with Galera Cluster 4 was made GA on 21 May 2020 and
announced on 25 May 2020
• Comes with wsrep API 26 and the Galera 4.5 library
• wsrep is integrated into the release of MySQL 8 that is shipped
• You can download and use it now: https://galeracluster.com/downloads/
#downloads

14. What new features are there?
• Streaming replication
• support for large transactions
• base platform for new features
• Group commit support
• Improved foreign key support
• Network resiliency

15. Streaming Replication
• The base for supporting huge transactions
• In Galera Cluster 3, a transaction processes on the “master node” (i.e. node
that client connected to, to execute the transaction) until commit time
• For large transactions, the writeset will be large, hard to process
• So wsrep_max_ws_size exists to prevent large transactions

16. Streaming Replication
• This is new in Galera Cluster 4 to enable running transactions of unlimited size
in a cluster
• You can of course still reject large transactions

17. What is a large transaction?
• LOAD DATA that is large…?
• wsrep_max_ws_rows and wsrep_max_ws_size. Limit the transaction rows to
128 KB and the transaction size to 1 GB. wsrep_max_ws_size has a
maximum upper limit of 2GB, beyond which it is rejected
• Guide to handle large transactions: http://galeracluster.com/library/kb/best/
large-transactions.html including the use of pt-archiver
• One practical test: https://www.percona.com/blog/2015/10/26/how-big-can-
your-galera-transactions-be/

18. Streaming Replication
• Transactions are replicated, gradually in small fragments, during transaction
processing
• i.e. before an actual commit, Galera replicates a number of small sized fragments
(transaction fragmentation)
• Size threshold for fragment replication is configurable
• Replicated fragments are applied in slave threads preserving the transaction state in
all cluster nodes
• fragments hold locks in all nodes and cannot be conflicted later
• Streaming replication allows nodes to process writesets greater than 2GB

19. Configuring Streaming Replication
• Session variables (dynamic):
• wsrep_trx_fragment_unit — unit metrics for fragmenting, options are bytes
(writesets in bytes), rows (number of rows modified), statements (number of
SQL statements issued)
• wsrep_trx_fragment_size — threshold size in units when fragments will be
replicated. 0 means no streaming.

20. Using Streaming Replication
• Due to excessive logging and elevated replication overhead, streaming
replication will cause degraded transaction throughput rate
• Best use case? Use streaming replication to cut large transactions
• Set the fragment size to around 10,000 rows
• Applications can also set streaming replication on/off on a need-by-need
basis (requires changes to application naturally)

21. New metadata — wsrep tables in mysql database
• There are some new Galera Cluster system tables
SHOW TABLES FROM mysql LIKE 'wsrep%';
+---------------------------+
| Tables_in_mysql (wsrep%) |
+---------------------------+
| wsrep_cluster |
| wsrep_cluster_members |
| wsrep_streaming_log |
+---------------------------+

22. wsrep_cluster
• Contains current view of the cluster, some identity information and also cluster capabilities
SELECT COLUMN_NAME FROM information_schema.columns
WHERE table_schema='mysql'
AND table_name='wsrep_cluster';
+------------------+
| COLUMN_NAME |
+------------------+
| cluster_uuid |
| view_id |
| view_seqno |
| protocol_version |
| capabilities |
+------------------+

23. wsrep_cluster_members
SELECT * FROM mysql.wsrep_cluster_members ORDER BY
node_name G
*************************** 1. row
***************************
node_uuid: e39d1774-7e2b-11e9-
b5b2-7696f81d30fb
cluster_uuid:
bd5fe1c3-7d80-11e9-8913-4f209d688a15
node_name: galera1
node_incoming_address: AUTO
*************************** 2. row
***************************
node_uuid: eb8fc512-7e2b-11e9-
bb74-3281cf207f60
cluster_uuid:
bd5fe1c3-7d80-11e9-8913-4f209d688a15
node_name: galera2
node_incoming_address: AUTO
*************************** 3. row
***************************
node_uuid: 2347a8ac-7e2c-11e9-b6f0-
da90a2d0a563
cluster_uuid:
bd5fe1c3-7d80-11e9-8913-4f209d688a15
node_name: galera3
node_incoming_address: AUTO

24. wsrep_streaming_log
• contains meta data and row events for ongoing streaming transactions,
writeset fragment per row
• SELECT * FROM mysql.wsrep_streaming_log G

25. wsrep functions
• WSREP_LAST_SEEN_GTID() — returns GTID for last written transaction
observed by client
• WSREP_LAST_WRITTEN_GTID() — returns GTID of the last write transaction
made by the client
• WSREP_SYNC_WAIT_UPTO_GTID() — blocks the client until the node applies
and commits the given transaction

26. Improved foreign key support
• Write set certification rules are now optimised to handle foreign keys
• If you have previously seen false conflicts in certification in logs, this will now
disappear as there’s a tremendous reduction in it

27. Group commit
• Now there is support for group commit that is natively integrated with the
MySQL 8 binary log
• Commit time concurrency controls have been reworked such that the commit
monitor is released as soon as the commit has been queued for a group
commit
• Transactions thus are committed in groups, while respecting the sequential
commit order

28. Poornetworkconnections?
•GaleraClusterisnowalotmoreresilientwhenitcomestohandlingpoor
networkconnections
•Handlingofirrecoverableerrorsduetopoornetworkconditionshasalsobeen
improved,sothatanodewillalways attempttoleavetheclustergracefullyif
itisnotpossibletorecoverfromerrorswithoutsacrificingdataconsistency
•Thisisgreatforgeo-distributedmulti-masterGaleraClusters

29. Rolling upgrades are supported
• From an existing wsrep 25 (e.g. MySQL 5.7) 3-node cluster
• Isolate a node (make one read only, you still have a 2-node cluster for read/write),
shutdown the server, upgrade to MySQL 8, start without wsrep_provider, run
mysql_upgrade, shutdown the server, restart with wsrep_provider, allow read only
access
• Now update node 2 as above
• Then shutdown node 1, allow read-write access again, and node 1 upgrade is complete
• Repeat for node 3

30. What isn’t here yet, but will be coming (esp. after MariaDB Server 10.5)
• Gcache encryption (now in MariaDB Enterprise 10.4)
• XA transaction support (needed for sharding cluster)
• Non-blocking DDL (coincides with other MariaDB Server non-blocking DDL
work)
• Cluster error voting (feature within Galera Cluster library, so might even make
it into a later release of 10.4)

31. Quick comparisons with other variants of Galera 4
Release dates
• MariaDB Server 10.4.6 was GA with Galera 4 on 18 June 2019
• Percona XtraDB Cluster (PXC) 8.0.18-9.3 was GA with Galera 4 on 29 April
2020
• Galera 4 with MySQL 8 from Codership was GA on 21 May 2020

32. Quick comparisons with other variants of Galera 4
Features
• MariaDB Server 10.4 includes use of backup locks which you can use with Mariabackup
for an SST with a lightweight lock
• Percona XtraDB Cluster (PXC) 8 includes features that you’d be familiar with Percona
Server…
• comes with ProxySQL
• comes with a Kubernetes operator
• enhanced encryption thanks to a Vault plugin
• mysql_upgrade happens on SST
• pxc_encrypt_cluster_traffic is enabled by default

33. In summary…
• Who are the developers of Galera Cluster? Codership.
• Who has the most developers of Galera Cluster? Codership.
• Who knows the code better than anyone? Codership.
• Who decides the roadmap for Galera Cluster? Codership. With our main
partner, MariaDB Corporation, and listening closely to the community.

34. What’s coming next?
• Galera 3.30
• Maintenance releases for 5.6 and 5.7
• More features in MySQL 8
• New management tools
• MariaDB 10.5

35. Colin Charles, colin.charles@galeracluster.com | 4 June 2020
Thank you. Questions?