Showing entries 1 to 10 of 370
10 Older Entries »
Displaying posts with tag: High Availability (reset)
How Not to do MySQL High Availability: Geographic Node Distribution with Galera-Based Replication Misuse

Let’s talk about MySQL high availability (HA) and synchronous replication once more.

It’s part of a longer series on some high availability reference architecture solutions over geographically distributed areas.

Part 1: Reference Architecture(s) for High Availability Solutions in Geographic Distributed Scenarios: Why Should I Care?

Part 2: MySQL High Availability On-Premises: A Geographically Distributed Scenario

The Problem

A question I often get from customers is: How do I achieve high availability in case if I need to spread my data in different, distant locations? …

[Read more]
Temporary tables are now allowed in transactions when GTIDs are enabled

There has been a recurring request from our users to remove a limit when using global transaction identifiers (GTIDs) and temporary tables together. The limit is that temporary tables cannot be created and dropped inside a transaction when GTIDs are turned on.…

Extending replication instrumentation: account for memory used in XCom

Version 8.0.12 added many great new features to MySQL. One of the new features included is the memory instrumentation of the XCom cache, which allows users to view and monitor the memory utilization of the cache by querying Performance Schema (PS).…

Extending replication instrumentation: an insight on transaction retries

MySQL 8.0.13 improves replication lag monitoring by extending the instrumentation for transaction transient errors. These temporary errors, which include lock timeouts caused by client transactions executing concurrently as the slave is replicating, do not stop the applier thread: instead, they cause a transaction to retry.…

Group Replication: coping with unreliable failure detection

Failure detection is a cornerstone of distributed systems as it determines which components are working properly or not, allowing it to tackle both network and host instabilities and failures. Like many other distributed systems, Group Replication (GR) requires a majority of correctly operating group members to work properly.…

On-demand primary election

Having a server acting as a primary with multiple secondaries is the most common setup when using Group Replication. Until now though, there was no way to change the current primary member while the group was running without causing some sort of disruption.…

Continuent Clustering versus AWS RDS/MySQL

Enterprises require high availability for their business-critical applications. Even the smallest unplanned outage or even a planned maintenance operation can cause lost sales, productivity, and erode customer confidence. Additionally, updating and retrieving data needs to be robust to keep up with user demand.

Let’s take a look at how Continuent Clustering helps enterprises keep their data available and globally scalable, and compare it to Amazon’s RDS running MySQL (RDS/MySQL).

Replicas and Failover What does RDS do?

Having multiple copies of a database is ideal for high availability. RDS/MySQL approaches this with “Multi-AZ” deployments. The term “Multi-AZ” here is a bit confusing, as enabling this simply means a single “failover replica” will be created in a different availability zone from the primary database instance. …

[Read more]
No-Downtime Cluster Software Upgrades

One important way to protect your data is to keep your Continuent Clustering software up-to-date.

A standard cluster deployment uses three nodes, which allows for no-downtime upgrades along with the ability to have a fully available cluster during maintenance.

Please note that with only two database cluster nodes, there is a window of vulnerability created by leaving zero failover candidates available when the lone slave is taken down for service.

The Best Practices: Staging Performing a No-Downtime Upgrade for a Staging Deployment

When upgrading a Staging-style deployment, all nodes are upgraded at once in parallel via the tools/tpm update command run from inside the staging directory on the staging host.

No Master switch happens, and all layers are restarted to use the new code. …

[Read more]
MySQL InnoDB Cluster – What’s new in the 8.0.13 (GA) release

The MySQL Development Team is very happy to announce the second 8.0 Maintenance Release of InnoDB Cluster!

In addition to bug fixes, 8.0.13 brings some new exciting features:

  • Defining the next primary instance “in line”
  • Defining the behavior of a server whenever it drops out of the cluster
  • Improved command line integration for DevOps type usage

Here are the highlights of this release!…

Picking a Deployment Method: Staging versus INI

Continuent Clustering is an extraordinarily flexible tool, with options at every layer of operation.

In this blog post, we will describe and discuss the two different methods for installing, updating and upgrading Continuent Clustering software.

When first designing a deployment, the question of installation methodology is answered by inspecting the environment and reviewing the customer’s specific needs.

Staging Deployment Methodology

All for One and One for All

Staging deployments were the original method of installing Continuent Clustering, and relied upon command-line tools to configure and install all cluster nodes at once from a central location called the staging server.

This staging server (which could be one of the cluster nodes) requires SSH access to …

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