Thank you for attending the Wednesday, June 21, 2017 high availability webinar titled Percona XtraDB Cluster, Galera Cluster, MySQL Group Replication. In this blog, I will provide answers to the Q & A for that webinar.
You can find the slides and a recording of the webinar here.
Is there a minimum MySQL server version for Group Replication?
MySQL Group Replication is GA since MySQL Community 5.7.17. This is the lowest version that you should use for the Group Replication feature. Otherwise, you are using a beta version.
Since 5.7.17 was the GA release, it’s strongly recommended you use the latest 5.7 minor release. Bugs get fixed and features added in each of the minor releases (as can be seen in the Limitations section in the slide deck).
In MySQL 5.6 and earlier versions, Group Replication is not supported. Note that Percona Server for MySQL 5.7.17 and beyond also ships with Group Replication.
Can I use Percona XtraDB Cluster with MariaDB v10.2? or must I use Percona Server for MySQL?
However, as Percona XtraDB Cluster is open source, it is possible that MariaDB/Codership implements our modifications into their codebase.
If Percona XtraDB Cluster does not allow InnoDB tables, how do we typically deal with applications that need to use MyISAM tables?
You cannot use MyISAM with Percona XtraDB Cluster, Galera or Group Replication. However, there is experimental MyISAM support in Galera/Percona XtraDB Cluster. But we strongly recommend that you don’t use this in production. It effectively executes all statements in Total Order Isolation, which results in bad performance.
What is a typical business use case for the Group Replication? I specifically like the writes order feature.
Typical use cases are:
- Environments with strict **durability** requirements
- Write to multiple nodes simultaneously while keeping data **consistent**
- Reducing failover time
- Using other nodes for read-scaling, where reading stale data is more difficult for the application (as opposed to standard asynchronous replication)
The use cases for Galera and Percona XtraDB Cluster are similar.
Where do you run ProxySQL, on a separate server? We are using HAProxy.
You can deploy ProxySQL in many different ways. One common method of installation is to run ProxySQL on a separate layer of servers (ensuring there is failover on this layer). Another commonly used method is to run a ProxySQL daemon on every application server.
Do you support KVM?
Yes, there are no limitations on virtualization solutions.
Can you give some examples of an “arbitrator”?
Some useful links:
What does Percona XtraDB add to make it more performant than InnoDB?
The scalability and performance improvement of Percona XtraDB are listed on the Percona Server for MySQL documentation page: https://www.percona.com/doc/
How scalable is Percona XtraDB Cluster storage wise? Do we have any limitations?
Storage happens through the storage engine (which is InnoDB). Percona XtraDB Cluster does not have any different limitations than Percona Server for MySQL or MySQL.
However, we need to also consider the practical side of things: the larger the cluster gets, the longer certain operations take. For example, when adding a new node to the cluster another node must be the donor and provide all the data. This will take substantially longer with larger datasets. Certain operational aspects might therefore become more complex.
Is there any development to add multiple nodes simultaneously?
No, at the moment only one node can join the cluster at the same time. Other nodes automatically wait until it is finished before joining.
Why does Galera say we cannot use READ COMMITTED isolation for multimaster mode, even though we can start the cluster with READ-COMMITTED?
You can use READ-COMMITTED as transaction isolation level. The limitation is that you cannot use SERIALIZABLE: http://galeracluster.com/
Galera Cluster and MariaDB currently do not prevent a user from using this transaction isolation level. Percona XtraDB Cluster implemented the strict mode to prevent these operations: https://www.percona.com/doc/
MariaDB 10.2 fixed the check constraints issue, When will Percona fix this issue?
There are currently no plans to support CHECK constraints in Percona Server for MySQL (and therefore Percona XtraDB Cluster as well).
As Percona Server is effectively a fully backwards-compatible (but modified) MySQL Community Server, CHECK constraints is a feature that normally would be implemented in MySQL Community first.
Can you share your performance benchmark git repository (if you have one)?
We don’t have a performance benchmark in git repository. You can get detailed information about this benchmark in this blog: Performance improvements in Percona XtraDB Cluster 5.7.17-29.20.
On your slide pointing to scalability charts, how many nodes did you run your test against?
We used a three-node cluster for this performance benchmark.
The product is using Master-Master replication. As such what do you mean when you talk about failover in such configuration?
“Master-Master” replication in the MySQL world means that you configure replication from node1 to node2, and from node2 to node1. However, since replication is asynchronous there are no consistency guarantees when writing to both nodes at the same time. Data can diverge, and nodes can end up with different data.
Master-Master is often used in order to failover from one master to another without having to reconfigure replication. All that is needed is to:
- Stop the traffic from the current master
- Let the other master sync up (usually almost immediately)
- Mark the old master read_only, set the new master as read_write
- Start traffic to the new master
Where do you maintain the cluster state?
All technologies automatically maintain the cluster state as you add and remove nodes.
What are the network/IP requirements for Proxy SQL?
There are no specific requirements. More documentation about ProxySQL can be found here: https://github.com/sysown/