Juju Charm - Percona XtraDB Cluster
Go to file
OpenDev Sysadmins 53579ec7bd OpenDev Migration Patch
This commit was bulk generated and pushed by the OpenDev sysadmins
as a part of the Git hosting and code review systems migration
detailed in these mailing list posts:

http://lists.openstack.org/pipermail/openstack-discuss/2019-March/003603.html
http://lists.openstack.org/pipermail/openstack-discuss/2019-April/004920.html

Attempts have been made to correct repository namespaces and
hostnames based on simple pattern matching, but it's possible some
were updated incorrectly or missed entirely. Please reach out to us
via the contact information listed at https://opendev.org/ with any
questions you may have.
2019-04-19 19:36:23 +00:00
actions Fix and tidy backup action 2016-05-20 10:05:44 +01:00
charmhelpers Replace openstack.org git:// URLs with https:// 2019-03-24 20:33:09 +00:00
hooks Merge "Notify peers bootstrap-uuid during upgrade-charm hook" into stable/17.02 2017-05-24 17:12:03 +00:00
keys Initial charm 2013-09-03 17:52:02 +01:00
lib Update tox.ini files from release-tools gold copy 2016-09-09 19:43:36 +00:00
ocf/percona mysql_monitor: Apply patch available in upstream PR #52 2015-04-07 12:51:43 -03:00
templates Disable hostname resolution 2017-01-25 09:27:01 +00:00
tests Notify peers bootstrap-uuid during upgrade-charm hook 2017-04-06 12:12:22 -03:00
unit_tests Notify peers bootstrap-uuid during upgrade-charm hook 2017-04-06 12:12:22 -03:00
.coveragerc Tweak coverage settings 2015-04-20 11:55:40 +01:00
.gitignore Add tox support for check/gate 2016-03-02 10:20:07 +00:00
.gitreview OpenDev Migration Patch 2019-04-19 19:36:23 +00:00
.testr.conf Add tox support for check/gate 2016-03-02 10:20:07 +00:00
Makefile Use bundletester for amulet test execution 2016-07-21 14:24:52 +01:00
README.md Merge "Wait until clustered before running client hooks" 2017-02-14 19:24:57 +00:00
actions.yaml Add backup action 2016-03-04 10:13:53 +00:00
charm-helpers-hooks.yaml Updates for stable branch creation 2017-02-23 15:49:12 -05:00
charm-helpers-tests.yaml Updates for stable branch creation 2017-02-23 15:49:12 -05:00
config.yaml Default performance schema to off 2017-01-09 13:59:24 -08:00
copyright [freyes,r=james-page] Ensure VIP is tied to a good mysqld instance. 2015-04-20 11:53:43 +01:00
hardening.yaml Add hardening support 2016-03-24 18:40:04 +00:00
metadata.yaml Enable access network for DNS HA 2016-09-27 08:22:33 +01:00
requirements.txt Fix pbr requirement 2016-04-13 10:25:30 +00:00
revision Rationalize configuration for percona/galera, add generic helpers for parsing mysql configuration options, use mysqlhelper for creation of SST user 2013-09-23 09:37:07 +01:00
setup.cfg Add unit tests for ha-relation-joined hook 2015-03-17 11:37:44 -03:00
test-requirements.txt Use bundletester for amulet test execution 2016-07-21 14:24:52 +01:00
tox.ini Update tox.ini files from release-tools gold copy 2016-09-09 19:43:36 +00:00

README.md

Overview

Percona XtraDB Cluster is a high availability and high scalability solution for MySQL clustering. Percona XtraDB Cluster integrates Percona Server with the Galera library of MySQL high availability solutions in a single product package which enables you to create a cost-effective MySQL cluster.

This charm deploys Percona XtraDB Cluster onto Ubuntu.

Usage

WARNING: Its critical that you follow the bootstrap process detailed in this document in order to end up with a running Active/Active Percona Cluster.

Proxy Configuration

If you are deploying this charm on MAAS or in an environment without direct access to the internet, you will need to allow access to repo.percona.com as the charm installs packages direct from the Percona respositories. If you are using squid-deb-proxy, follow the steps below:

echo "repo.percona.com" | sudo tee /etc/squid-deb-proxy/mirror-dstdomain.acl.d/40-percona
sudo service squid-deb-proxy restart

Deployment

The first service unit deployed acts as the seed node for the rest of the cluster; in order for the cluster to function correctly, the same MySQL passwords must be used across all nodes:

cat > percona.yaml << EOF
percona-cluster:
    root-password: my-root-password
    sst-password: my-sst-password
EOF

Once you have created this file, you can deploy the first seed unit:

juju deploy --config percona.yaml percona-cluster

Once this node is full operational, you can add extra units one at a time to the deployment:

juju add-unit percona-cluster

A minimum cluster size of three units is recommended.

Memory Configuration

Percona Cluster is extremely memory sensitive. Setting memory values too low will give poor performance. Setting them too high will create problems that are very difficult to diagnose. Please take time to evaluate these settings for each deployment environment rather than copying and pasting bundle configurations.

The Percona Cluster charm needs to be able to be deployed in small low memory development environments as well as high performance production environments. The charm configuration opinionated defaults favor the developer environment in order to ease initial testing. Production environments need to consider carefully the memory requirements for the hardware or cloud in use. Consult a MySQL memory calculator [2] to understand the implications of the values.

Between the 5.5 and 5.6 releases a significant default was changed. The performance schema [1] defaulted to on for 5.6 and later. This allocates all the memory that would be required to handle max-connections plus several other memory settings. With 5.5 memory was allocated during runtime as needed.

The charm now makes performance schema configurable and defaults to off (False). With the performance schema turned off memory is allocated when needed during run time. It is important to understand this can lead to run time memory exhaustion if the configuration values are set too high. Consult a MySQL memory calculator [2] to understand the implications of the values.

Particularly consider the max-connections setting, this value is a balance between connection exhaustion and memory exhaustion. Occasionally connection exhaustion occurs in large production HA clouds with max-connections less than 2000. The common practice became to set max-connections unrealistically high near 10k or 20k. In the move to 5.6 on Xenial this became a problem as Percona would fail to start up or behave erratically as memory exhaustion occurred on the host due to performance schema being turned on. Even with the default now turned off this value should be carefully considered against the production requirements and resources available.

[1] http://dev.mysql.com/doc/relnotes/mysql/5.6/en/news-5-6-6.html#mysqld-5-6-6-performance-schema [2] http://www.mysqlcalculator.com/

HA/Clustering

When more than one unit of the charm is deployed with the hacluster charm the percona charm will bring up an Active/Active cluster. The process of clustering the units together takes some time. Due to the nature of asynchronous hook execution it is possible client relationship hooks may be executed before the cluster is complete. In some cases, this can lead to client charm errors.

To guarantee client relation hooks will not be executed until clustering is completed use the min-cluster-size configuration setting:

juju deploy -n 3 percona-cluster
juju config percona-cluster min-cluster-size=3

When min-cluster-size is not set the charm will still cluster, however, there are no guarantees client relation hooks will not execute before it is complete.

Single unit deployments behave as expected.

There are two mutually exclusive high availability options: using virtual IP(s) or DNS. In both cases, a relationship to hacluster is required which provides the corosync back end HA functionality.

To use virtual IP(s) the clustered nodes must be on the same subnet such that the VIP is a valid IP on the subnet for one of the node's interfaces and each node has an interface in said subnet. The VIP becomes a highly-available API endpoint.

At a minimum, the config option 'vip' must be set in order to use virtual IP HA. If multiple networks are being used, a VIP should be provided for each network, separated by spaces. Optionally, vip_iface or vip_cidr may be specified.

To use DNS high availability there are several prerequisites. However, DNS HA does not require the clustered nodes to be on the same subnet. Currently the DNS HA feature is only available for MAAS 2.0 or greater environments. MAAS 2.0 requires Juju 2.0 or greater. The clustered nodes must have static or "reserved" IP addresses registered in MAAS. The DNS hostname(s) must be pre-registered in MAAS before use with DNS HA.

At a minimum, the config option 'dns-ha' must be set to true and 'os-access-hostname' must be set in order to use DNS HA. The charm will throw an exception in the following circumstances: If neither 'vip' nor 'dns-ha' is set and the charm is related to hacluster If both 'vip' and 'dns-ha' are set as they are mutually exclusive If 'dns-ha' is set and os-access-hostname is not set

Network Space support

This charm supports the use of Juju Network Spaces, allowing the charm to be bound to network space configurations managed directly by Juju. This is only supported with Juju 2.0 and above.

You can ensure that database connections are bound to a specific network space by binding the appropriate interfaces:

juju deploy percona-cluster --bind "shared-db=internal-space"

alternatively these can also be provided as part of a juju native bundle configuration:

percona-cluster:
  charm: cs:xenial/percona-cluster
  num_units: 1
  bindings:
    shared-db: internal-space

NOTE: Spaces must be configured in the underlying provider prior to attempting to use them.

NOTE: Existing deployments using the access-network configuration option will continue to function; this option is preferred over any network space binding provided if set.

Limitiations

Note that Percona XtraDB Cluster is not a 'scale-out' MySQL solution; reads and writes are channelled through a single service unit and synchronously replicated to other nodes in the cluster; reads/writes are as slow as the slowest node you have in your deployment.