442 blog posts in 12 categories
We’re particularly excited about this year’s Percona LiveLondon MySQL Conference. The line-up of speakers & topics looks excellent and it’s good to see speakers from Oracle, Percona, the MariaDB Foundation (amongst others) scheduled at the same event.
Data protection is vital for DB admins, especially when it involves data that is accessed and updated 24 hours a day. Clustering and replication are techniques that provide protection against failures, but what if a user or DBA issues a detrimental command against one of the databases? A user might erroneously delete or update the contents of one or more tables, drop database objects that are still needed during an update to an application, or run a large batch update that fails midway. How do we recover lost data?
Galera Cluster features and benefits
Support for MySQL 5.6
Integration with MySQL Global Transaction Identifiers
Mixing Galera synchronous replication and asynchronous MySQL replication
Galera uses a preallocated file with a specific size called gcache, used to store the writesets in circular buffer style. By default, its size is 128MB. In this post, we are going to explore how to leverage gcache to improve the operation of a Galera cluster.
As you might already know, ClusterControl runs on a dedicated host. Failure of the ClusterControl host (or the datacenter it is running in) does not affect your running database cluster, however you cannot manage the cluster during that time. This is inconvenient. To guard against this, it is possible to deploy a standby ClusterControl server and increase the availability of your management infrastructure.
Database vendors regularly issue critical patch updates to address software bugs or known vulnerabilities, but for a variety of reasons, organizations are often unable to install them in a timely manner, if at all. Evidence suggests that companies are actually getting worse at patching databases, with an increased number violating compliance standards and governance policies1.
Join this technical webinar to learn about the new features in the latest Galera 3.0 release.
You'll learn how Galera integrates with MySQL 5.6 and Global Transaction IDs to enable cross-datacenter and cloud replication over high latency networks. The benefits are clear; a globally distributed MySQL setup across regions to deliver Severalnines availability and real-time responsiveness.
For those of you who know Severalnines and maybe use some of our tools & products, you’ll know that we provide our users with a monthly summary of all the resources & tools that we’re publishing. Since this is publicly available material, we thought it’d be useful also for the broader open source database community.
Galera cluster has known limitations, one of them is that it uses cluster-wide optimistic locking. This may cause some transactions to rollback. With an increasing number of writeable masters, the transaction rollback rate may increase, especially if there is write contention on the same dataset. It is of course possible to retry the transaction and perhaps it will COMMIT in the retries, but this will add to the transaction latency. However, some designs are deadlock prone, e.g sequence tables. In this blog we present how you can minimize the risk for deadlocks due to the design of Galera.
BitTorrent Sync is a simple replication application providing encrypted bidirectional file transfers that can run behind NAT and is specifically designed to handle large files. By leveraging the simplicity of Bittorrent Sync, we can transfer backup files away from our cluster, enhancing the backups availability and reducing the cost of broken backup, where you can regularly verify your backups off-site.