blog
Webinar Replay: Galera 3.0 Introduction and Cluster Management – with MySQL 5.6, Global Transaction IDs and WAN
Webinar topics:
- Galera Cluster features and benefits
- Support for MySQL 5.6
- Integration with MySQL Global Transaction Identifiers
- Mixing Galera synchronous replication and asynchronous MySQL replication
- Deploying in WAN and Cloud environments
- Handling high-latency networks
- Cluster Management and Monitoring
- Demo
We had a lot of questions during and also after the webinar sessions, so we thought we’d post all the answers here, as well as the video replay and slides.
If you have any additional questions, feel free to contact us or post them below in the comments section.
Webinar Slides
Galera 3.0 Introduction slides
Galera Monitoring & Management slides
If you would like to schedule a live demo of ClusterControl, please contact us here.
Q&A
Q. Are there ways to distribute data across nodes instead of all data on every node?
A. All nodes in a Galera cluster have the same data, so users can manually partition across galera clusters.
Q. How about 3.0 integration with MariaDB?
A. 3.0 integration for MariaDB is under way, the MariaDB team and Codership are working on MariaDB Galera Cluster for MariaDB 10.
Q. How many nodes in a cluster can we scale to?
A. We have seen up to 9 nodes per cluster in production, but the limit depends on application workload and hardware/network setup.
Q. Why is there an additional 100-300ms commit latency with the WAN Replication?
A. WAN replication latency depends on networking. 100ms is typical delay between US-Europe connections, and 300 ms if you need to replicate world-wide. Most common WAN deployments are in metropols, with networks where round trip times are usually below 10 ms.
Q. Will Galera 3.0 nodes work with Galera 2.0 nodes?
A. Galera 3.0 is backwards compatible with Galera 2.0, you can do rolling upgrade for your cluster.
Q. When will 3.0/mysql 5.6 wsrep API be out of beta? We are testing 5.5/2.0 now, and likely rolling out in about 3 months. Do you think 5.6/3.0 will be ready by then?
A. Codership is targeting to get 3.0 GA released during November 2013.
Q. Does ClusterControl implement some simple data consistency check between Galera nodes?
A. Not at the moment, but this feature is on our near-term roadmap, so stay tuned.
Q. Is there any improvement in the ‘deadlock’ handling ie. in a hybrid setup Master-> Galera Cluster, if there is a deadlock that occured from the Master, how is that handled?
A. If there is MySQL master and its replication conflicts with transactions in Galera Cluster, Galera rejects the conflicting replication events. It may be that, if incoming replication is STATEMENT based, there are some phantom conflicts (not on row level, but on statement execution level), and Galera aborts unnecessarily some mysql replication events. If that is the case, switching to ROW format would help. Galera slave could be optimized to retry replication events, the Codership team might look into adding this as an enhancement.
Q. Will the FreeBSD builds be installed via ports, or pkg, or pkg-ng?
A. Currently Codership have freeBSD packages built, but are looking for integrating with ports installation in the future. The FreeBSD porting was sponsored by Perceptyx.
Q. When using MySQL Replication over WAN, is there failover to using a different Galera node as the master or the slave?
A. Yes, using GTIDs to know which binlog position to continue from after failover.
Q. When using Galera is there a general rule of thumb for RAM requirements? For example if total databases are 2 GB in size, would nodes with 4 GB RAM each be ok or what sort of specs would you suggest based on database size?
A. Memory overhead of Galera depends on the size of transactions, specifically on the number of rows modified or referenced by transaction. Normally it is quite low, but from time to time people tend to delete several million rows at once and then memory used by Galera grows substantially (even gigabytes) and currently there is no way to reclaim it back (this is not a memory leak, it is memory reserved for certification of the biggest transaction seen). Deleting large number of rows at once is a generally bad practice. TRUNCATE command does not cause any memory overhead as well. In general, leave 5-10% of RAM for Galera operation (meaning that innodb_buffer_pool_size should be somewhat smaller than in a standalone server).
Q. Does the single link cross data centers decrease replication performance? I would expect a single link over the WAN to increase cluster sync times.
A. Assuming single link refers to single segment to segment connection, then:
- it might add some negligible latency to replication. The latency is noticeable if you test it in LAN (naturally), but in WAN it should not matter,
- it does not affect SST/IST (initial node synchronization) as they are done outside replication (and anyways are done point-to-point),
- it allows for intelligent state transfer donor selection, so if anything, it speeds things up.
About Galera Cluster
Galera Cluster for MySQL is a true multi-master MySQL replication plugin, and has been proven in mission-critical infrastructures of companies like Ping Identity, AVG Technologies, KPN and HP Cloud DNS. Read the Galera tutorial for more information.
About ClusterControl
Setting up and maintaining a database cluster can be tricky. ClusterControl gives you the power to deploy, manage, monitor and scale entire clusters efficiently and reliably. ClusterControl supports a variety of SQL and NoSQL cluster topologies, as well as SQL load balancing via HAProxy.
If you would like to schedule a live demo of ClusterControl, please contact us here.
