To resolve a critical regression, Percona announces the release of Percona XtraDB Cluster 5.7.23-31.31.2 on October 2, 2018 Binaries are available from the downloads section or from our software repositories.
This release resolves a critical regression in Galera’s wsrep library and supersedes 5.7.23-31.31
Percona XtraDB Cluster 5.7.23-31.31.2 is now the current release, based on the following:
Your database cluster contains your most business-critical data. The slave nodes must be online, healthy and in sync with the master in order to be viable failover candidates.
This means keeping a close watch on the health of the databases nodes from many perspectives, from ensuring sufficient disk space to testing that replication traffic is flowing.
A robust monitoring setup is essential for cluster health and viability – if your replicator goes offline and you do not know about it, then that slave becomes effectively useless because it has stale data.
Big Brother is Watching You! The Power of Nagios
Even while you sleep, your servers are busy, and you simply cannot keep watch all the time. Now, more than ever, with global deployments, it is literally impossible to watch everything all the time.
Enter Nagios, you best big brother ever. As a long-time player in the monitoring market, Nagios has both …
[Read more]This release has been superseded by 5.7.23-31.31.2 after a critical regression was found. Please update to the latest release.
Percona is glad to announce the release of Percona XtraDB Cluster 5.7.23-31.31 on September 26, 2018. Binaries are available from the downloads section or from our software repositories.
Percona XtraDB Cluster 5.7.23-31.31 is now the current release, based on the following:
[Read more]Continuent Clustering support true distributed multimaster clustering. In this topology, there are cross-site replicator services for each remote site. In a 3-site configuration, there are a total of 9 replication streams to manage.
Continuent Clustering also offers a graphical administration tool called the Tungsten Dashboard to help with your management burden. The GUI makes the deployment much easier to visualize and administer.
For our example, we will have a Composite Multimaster dataservice called global with three active, writable member clusters (one per site), east, west and north.
Dashboard Summary View
In the summary, collapsed view, the composite service and all member clusters are listed with associated information and controls. Note that the Type for the composite dataservice global is CompMM …
[Read more]Percona announces the release of Percona XtraDB Cluster 5.6.41-28.28 (PXC) on September 18, 2018. Binaries are available from the downloads section or our software repositories.
Percona XtraDB Cluster 5.6.41-28.28 is now the current release, based on the following:
Fixed Bugs
Join Percona Chief Evangelist Colin Charles as he covers happenings, gives pointers and provides musings on the open source database community.
The call for submitting a talk to Percona Live Europe 2018 is closing today, and while there may be a short extension, have you already got your talk submitted? I suggest doing so ASAP!
I’m sure many of you have heard of cryptocurrencies, the blockchain, and so on. But how many of you realiize that Coinbase, an application that handles cryptocurrency trades, matching book orders, and more, is powered by MongoDB? With the hype and growth in interest in late 2017, Coinbase has had to scale. They gave an excellent talk at MongoDB World, titled MongoDB & Crypto Mania (the video is worth a watch), and they’ve also written a blog post, …
[Read more]In this blog post, we talk about how to run applications across multiple clouds (i.e. AWS, Google Cloud, Microsoft Azure) using Continuent Clustering. You want your business-critical applications to withstand node, datacenter, availability-zone or regional failures. For SaaS apps, you also want to bring data close to your application users for faster response times and a better user experience. With cross-cloud capability, Continuent also helps avoid lock-in to any particular cloud provider.
The key to success for the database layer is to be available and respond rapidly.
From both a business and operational perspective, spreading the application across cloud environments from different vendors provides significant protection against vendor-specific outages and vendor lock-in. Running on multiple platforms provides greater …
[Read more]In this blog post, we demonstrate how to convert a single standalone cluster into a Composite Primary/DR topology running in two data centers.
Our example starting cluster has 5 nodes (1 master and 4 slaves) and uses service name alpha. Our target cluster will have 6 nodes (3 per cluster) in 2 member clusters alpha_east and alpha_west in composite service alpha.
This means that we will reuse the existing service name alpha as the name of the new composite service, and create two new service names, one for each cluster (alpha_east and alpha_west).
Below is an INI file extract example for our starting standalone cluster with 5 nodes:
[defaults] ... [alpha] connectors=db1,db2,db3,db4,db5 master=db1 members=db1,db2,db3,db4,db5 topology=clustered
To convert the above configuration to a Composite Primary/DR:
shell> stopall…
What if I want the cluster to be less sensitive to network, especially WAN latency?
Continuent Clustering supports having clusters at multiple sites with active-active replication meshing them together.
This is extraordinarily powerful, yet at times high network latency can make it harder for messaging between the sites to arrive in a timely manner.
This is evidenced by seeing the following in the Manager log
files named tmsvc.log:
2018/07/08 16:51:05 | db3 | INFO [Rule_0604$u58$_DETECT_UNREACHABLE_REMOTE_SERVICE1555959201] - CONSEQUENCE: [Sun Jul 08 16:51:04 UTC 2018] CLUSTER global/omega(state=UNREACHABLE) ... 2018/07/08 16:51:42 | db3 | INFO [Rule_2025$u58$_REPORT_COMPONENT_STATE_TRANSITIONS1542395297] - CLUSTER 'omega@global' STATE TRANSITION UNREACHABLE => ONLINE
The delta is 37 seconds in the above example between state=UNREACHABLE and UNREACHABLE => ONLINE
The default …
[Read more]MySQL semisynchronous replication provides improved data integrity because when a commit returns successfully, it’s known that the data exists in at least two places – the master and its slave. In this blog post, we review some of the MySQL hosting configurations that influence the data integrity and performance aspects of semisynchronous replication. We’ll be using InnoDB storage engine and GTID-based replication in a 3-node replica set (master and 2 slaves), which will ensure there is redundancy in the slaves. This means that if there are issues with one slave, we can fall back on the other.
Configurations Applicable to Both Master and Slave Nodes
