October 23, 2013
By Severalnines

 

Last week, the Severalnines & Codership teams came together to co-host two webinar sessions on Galera 3.0, MySQL 5.6, Global Transaction IDs and WAN. The sessions were held during EMEA/APAC as well as NA/LATAM timezones, which worked out quite nicely. Our speakers were Seppo Jaakola from Codership & Vinay Joosery from Severalnines

 

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.