The Library

Related Documents

Installing Galera Cluster

Length: 946 words; Published: October 20, 2014; Topic: General; Level: Beginner

Galera Cluster requires server hardware for a minimum of three nodes.

If your cluster runs on a single switch, use three nodes. If your cluster spans switches, use three switches. If your cluster spans networks, use three networks. If your cluster spans data centers, use three data centers. This ensures that the cluster can maintain a Primary Component in the event of network outages.

Hardware Requirements

For server hardware, each node requires at a minimum the following components:

  • 1 GHz single core CPU;
  • 512 MB RAM; and
  • 100 Mbps network connectivity

Note

Galera Cluster may occasionally crash when run on limited hardware due to insufficient memory. To prevent this, make sure that you have allocated a sufficient amount of swap space. For more information on how to create swap space, see Configuring Swap Space.

Software Requirements

For software, each node in the cluster requires at a minimum the following:

  • Linux or FreeBSD operating system installed;
  • MySQL or MariaDB server with the wsrep API patch; and
  • Galera Replication Plugin installed.

Note

Binary installation packages for Galera Cluster include the database server with the wsrep API patch. When building from source, though, you must apply this patch manually.

Preparing the Server

Before you begin the installation process, there are a few tasks that you need to do to prepare the servers for Galera Cluster. You must perform the following steps on each node in your cluster.

Disabling SELinux for mysqld

If SELinux (Security-Enhanced Linux) is enabled on the servers, it may block mysqld from performing required operations. You must either disable SELinux for mysqld or configure it to allow mysqld to run external programs and open listen sockets on unprivileged ports—that is, operations that an unprivileged user may do.

To disable SELinux for mysqld, execute the following from the command-line:

# semanage permissive -a mysqld_t

This command switches SELinux into permissive mode when it registers activity from the database server. While this is fine during the installation and configuration process, it is not in general a good policy to disable security applications.

Rather than disable SELinux, so that your may use it along with Galera Cluster, you will need to create an access policy. This will allow SELinux to understand and allow normal operations from the database server. For information on how to create such an access policy, see SELinux.

Note

For more information on writing SELinux policies, see SELinux and MySQL.

Firewall Configuration

Next, you will need to update the firewall settings on each node so that they may communicate with the cluster. How you do this varies depending upon your distribution and the particular firewall software that you use.

Note

If there is a NAT firewall between the nodes, you must configure it to allow for direct connections between the nodes, such as through port forwarding.

As an example, to open ports between trusted hosts using iptables, you would execute something like the following on each node:

# iptables --append INPUT --protocol tcp \
      --source 64.57.102.34 --jump ACCEPT
# iptables --apend INPUT --protocol tcp \
      --source 193.166.33.20 --jump ACCEPT
# iptables --append INPUT --protocol tcp \
      --source 193.125.4.10 --jump ACCEPT

This causes packet filtering on the kernel to accept TCP connections between the given IP addresses.

Warning

The IP addresses in the example are for demonstration purposes only. Use the real values from your nodes and netmask in the iptables configuration for your cluster.

The updated packet filtering rules take effect immediately, but are not persistent. When the server reboots, it reverts to default packet filtering rules, which do not include your updates. To use these rules after rebooting, you need to save them as defaults.

For systems that use init, run the following command:

# service save iptables

For systems that use systemd, you need to save the current packet filtering rules to the path that the iptables unit reads when it starts. This path can vary by distribution, but you can normally find it in the /etc directory.

  • /etc/sysconfig/iptables
  • /etc/iptables/iptables.rules

When you find the relevant file, you can save the rules using the iptables-save command, then redirecting the output to overwrite this file.

# iptables-save > /etc/sysconfig/iptables

When iptables starts it now reads the new defaults, with your updates to the firewall.

For more information on setting up the firewall for Galera Cluster and other programs for configuring packet filtering in Linux and FreeBSD, see Firewall Settings.

Disabling AppArmor

By default, some servers—for instance, Ubuntu—include AppArmor, which may prevent mysqld from opening additional ports or running scripts. You must disable AppArmor or configure it to allow mysqld to run external programs and open listen sockets on unprivileged ports.

To disable AppArmor, run the following commands:

$ sudo ln -s /etc/apparmor.d/usr.sbin.mysqld /etc/apparmor.d/disable/usr.sbin.mysqld

You will then need to tell AppArmor to reload profile:

$ sudo apparmor_parser -R /etc/apparmor.d/usr.sbin.mysqld

In some cases you may also need to restart AppArmor. If your system uses init scripts, run the following command:

$ sudo service apparmor restart

If instead, your system uses systemd, run the following command instead:

$ sudo systemctl restart apparmor

Installing Galera Cluster

There are two versions of Galera Cluster for MySQL: the original Codership reference implementation and MariaDB Galera Cluster. For each database server, binary packages are available for Debian- and RPM-based Linux distributions, or you can build them from source.

MariaDB Galera Cluster

Note

In the event that you build or install Galera Cluster over an existing standalone instance of MySQL or MariaDB, there are some additional steps that you need to take in order to update your system to the new database server. For more information, see Migration.

Related Documents