Marketo provides the leading cloud-based marketing software platform for companies of all sizes to build and sustain engaging customer relationships. Marketo's SaaS platform runs on MySQL and has faced data management challenges common to all 24x7 SaaS businesses:

Keeping data available regardless of DBMS failures or planned maintenance Utilizing hardware optimized for multi-terabyte MySQL

Join Continuent and our customers Modernizing Medicine and Marketo to learn how to run business-critical MySQL applications in the cloud or on-premises. Modernizing Medicine is a fast-growing SaaS company, offering electronic medical records management solution. Matthew Lang, Sr. Site Reliability Engineer at Modernizing Medicine, describes how Modernizing Medicine serves thousands of customers

With its distributed, shared-nothing architecture, MySQL Cluster has been designed to deliver 99.999% availability ensuring resilience to failures and the ability to perform scheduled maintenance without downtime.

With the MySQL Cluster training course, in 3 days, you learn important clustering concepts as well as how to install and configure MySQL Cluster and manage cluster nodes. 

Below is a selection of events already on the schedule.

If you're setting up MySQL Cluster on Oracle Linux or another Linux such as Red Hat, CentOS or Fedora, you might have come across some problems getting the nodes to communicate. There are two ways you might bump into problems with network connectivity: The iptables firewall, and SELinux. These security mechanisms might prevent your various nodes—management, data, and API—from communicating with each other in various ways and with various symptoms.

Let's have a look at what you're likely to see. 

Data nodes stuck at "starting"

The first thing you might notice is that your data nodes get stuck in the "starting" state. Running show in the management client gives something like this:

[ndbd(NDB)]     2 node(s)
id=2    @192.168.56.211  (mysql-5.6.11 ndb-7.3.2, Nodegroup: 0, Master)
id=3    @192.168.56.212  (mysql-5.6.11 ndb-7.3.2, starting, Nodegroup: 0)

...and it never moves away from starting.

…

June 17, 2013 By Severalnines

Magento is an open-source e-commerce platform built on Zend PHP and MySQL. It is widely adopted by online retailers with some 150,000 sites known to use it. Single server setups are easy to set up, but if your store is a huge success, then you probably need to think about clustering your environment with multiple servers. Clustering is done at the web, database and file-system level, as all web nodes need access to catalog images. 

This post is similar to our previous posts on scaling Drupal and WordPress performance, and focuses on how to scale Magento on multiple servers. The software used is Magento version 1.7.0.2 , nginx, HAProxy, MySQL Galera …

MySQL Cluster enables users to meet the database challenges of next generation web, cloud, and communications services with uncompromising scalability, uptime and agility. With the MySQL Cluster training course:

Below is a selection of events on the schedule for this 3 day instructor-led course:

Playing around with Percona Replication Manager, and being new to Pacemaker, some errors were somewhat cryptic.

May 26 09:53:39 [2181] ha01.localdomain    pengine:   notice: unpack_rsc_op:    Preventing p_mysql from re-starting on ha02.localdomain: operation monitor failed 'not installed' (rc=5)
May 26 09:53:39 [2181] ha01.localdomain    pengine:   notice: unpack_rsc_op:    Preventing op from re-starting on ha02.localdomain: operation monitor failed 'not installed' (rc=5)

First, it says here that I have ‘operation monitor failed’ on node ha02.localdomain. This error simply means ‘I cannot run the operation monitor because it is not installed’. Where does this operation supposed to come from, from the resource agent. Turns out, I did not have the mysql resource agent in place under /usr/lib/ocf/resource.d/percona.

May 27 23:24:29 [2013] ha01.localdomain crm_resource:    error: unpack_rsc_op:  Preventing reader_vip_2 from …

We’ve told you all about MySQL mult-master replication’s limitations. If you write to two masters it is bound to fail for myriad reasons. Now what? Do what the pros do that’s what. A. Don’t write to both masters Using multi-master replication works great as long as you do so in active-passive mode. Never write to [...]

One of the first things we do when preparing a client’s infrastructure for Galera deployment is see whether their schema is suitable.

• Avoiding quirks and edge cases, we can say that Galera simply requires all tables to be InnoDB and also have a PRIMARY KEY (obviously having a PK in InnoDB is important anyway, for InnoDB-internal reasons).
• We want to know about FULLTEXT indexes. With recent InnoDB versions also supporting FULLTEXT we need to check not just whether a table has such an index, but actually which engine it is.
• Spatial indexes. While both InnoDB and MyISAM can deal with spatial datatypes (POINT, GEOMETRY, etc), only MyISAM has the spatial indexes.

Naturally, checking a schema in the server is more effective than going through other sources and possibly missing bits. On the downside, the only viable way to get this info out of MariaDB is INFORMATION_SCHEMA, but because of the way …

If the following items items describe what you need in a high-availability solution, then MySQL Cluster is for you:

• High scale, reads and writes
• 99.999% availability
• Real-time
• SQL and NoSQL
• Low TCO

And what better way to get started on MySQL Cluster than taking the authentic MySQL Cluster training course.

In this 3-day course, you learn important cluster concepts and get hands-on experience installing, configuring and managing a cluster. Some events already on the schedule for this course include: