Showing entries 1 to 10 of 235
10 Older Entries »
Displaying posts with tag: galera (reset)
Geo-distributed multi-master Galera Cluster on Amazon EC2. Join Codership at Amazon re:Invent Las Vegas 26-29 November

Implementing Galera Cluster on Amazon EC2  provides several advantages for companies. Multi-master clustering comes out of the box as a default in Galera. Users can read and write from any database providing fast local writes and reads. Galera handles conflicts automatically if your application is writing to the same row. Nodes can be added and deleted on the fly if you need more capacity and elasticity. New nodes can join automatically. In the case data center downtime Galera provides disaster recovery and Galera Cluster takes care of the split brain situation too. Automated failover and recovery allow the database to continually service the application transparently.

Meet the developers and experts of Galera Cluster in Amazon re:Invent Las Vegas 26-29 November. You can find us at Venetian hotel, booth number 738.

Galera Cluster supports high volume traffic at Paytrail and THINQ

Paytrail

 

“Galera Cluster has supported our growth all the way from a small number of transactions to high volume  traffic. Since 2012 our payment service with Galera has processed over 4 billion euros worth of product and service sales. Today we help 10 000+ webshops and online services in several countries to provide a pleasant shopping experience to their customers”

 

THINQ

 

“We’re very happy how Galera Cluster facilitated automated failover eliminating downtime for THINQ services that programmatically route millions of phone calls. The comprehensive Codership documentation includes, for example, the AppArmor package settings necessary to make Galera Cluster nodes more secure. ”

North Carolina based, THINQ is a cloud-based software company that develops Business as a Service (BaaS) solutions for the telecommunications industry. Partners …

[Read more]
CRITICAL UPDATE for Percona XtraDB Cluster users: 5.7.23-31.31.2 Is Now Available

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:

[Read more]
Percona XtraDB Cluster 5.7.23-31.31 Is Now Available

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]
Percona XtraDB Cluster 5.6.41-28.28 Is Now Available

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

[Read more]
Releasing Galera Cluster 3.24 with Improved Deadlock Error Management

Codership is pleased to announce the release of Galera Replication library 3.24, implementing wsrep API version 25.  The new release includes improved deadlock error management with foreign keys and security fixes. As always, Galera Cluster is now available as targeted packages and package repositories for a number of Linux distributions, including Ubuntu, Red Hat, Debian, CentOS, OpenSUSE and SLES, as well as FreeBSD. Obtaining packages using a package repository removes the need to download individual files and facilitates the easy deployment and upgrade of Galera Cluster nodes.

This release incorporates all changes up to MySQL 5.7.23, MySQL 5.6.41 and MySQL 5.5.61.

 

Galera Replication Library 3.24
New features and notable fixes in Galera replication since last binary release by Codership (3.23)

* A support for new …

[Read more]
Question about Semi-Synchronous Replication: the Answer with All the Details

I was recently asked a question by mail about MySQL Lossless Semi-Synchronous Replication. As I think the answer could benefit many people, I am answering it in a blog post. The answer brings us to the internals of transaction committing, of semi-synchronous replication, of MySQL (server) crash recovery, and of storage engine (InnoDB) crash recovery. I am also debunking some misconceptions that I have often seen and heard repeated by many. Let’s start by stating one of those misconceptions.

One of those misconceptions is the following (this is NOT true): semi-synchronous enabled slaves are always the most up-to-date slaves (again, this is NOT true). If you hear it yourself, then please call people out on it to avoid this spreading more. Even if some slaves have semi-synchronous replication disabled (I will use semi-sync for …

[Read more]
ProxySQL Series : Percona Cluster/MariaDB Cluster (Galera) Read-write Split

ProxySQL is the most preferred and is widely used for load-balancing MySQL workload, thanks to Rene Cannon & Team for the great tool, and kudos on the recent release of ProxySQL 1.4.10, with a lot of bug fixes. ProxySQL is simple in design, lightweight, highly efficient and feature rich, We have been working with ProxySQL in production for our client quite a sometime, we have also shared some of our encounters/experience and use cases in the below blogs.

[Read more]
Galera cluster to AWS Aurora migration & HA_ERR_FOUND_DUPP_KEY

In this post we will see a case study of a Galera Cluster migration to AWS Aurora and quick solution to the replication issue. A friend received an error in a Master-Master replication as follows: Could not execute Write_rows event on table _database._table; Duplicate entry '65eJ8RmzASppBuQD2Iz73AAy8gPKIEmP-2018-08-03 08:30:03' for key 'PRIMARY', Error_code: 1062; handler error HA_ERR_FOUND_DUPP_KEY; […]

MariaDB Galera cluster and GTID

In MariaDB 10.2.12, these two don’t yet work together. GTID = Global Transaction ID.  In the master-slave asynchronous replication realm, this means that you can reconnect a slave to another server (change its master) and it’ll happily continue replicating from the correct point.  No more fussing with filenames and offsets (which of course will both differ on different machines).

So in concept the GTIID is “globally” unique – that means it’s consistent across an entire infra: a binlogged write transaction will have the same GTID no matter on which machine you look at it.

  • OK: if you are transitioning from async replication to Galera cluster, and have a cluster as slave of the old infra, then GTID will work fine.
  • PROBLEM: if you want to run an async slave in a Galera cluster, GTID will currently not work. At least not reliably.

The overview issue is …

[Read more]
Showing entries 1 to 10 of 235
10 Older Entries »