Flow control is not a new term, and we have already heard it a lot of times in Percona XtraDB Cluster/Galera-based environments.  In very simple terms, it means the cluster node can’t keep up with the cluster write pace. The write rate is too high, or the nodes are oversaturated. Flow control helps avoid excessive […]

In this article, we will discuss errant Transaction /GTID and how we can solve them with the Orchestrator tool.

Orchestrator is a MySQL high availability and replication management tool that runs as a service and provides command line access, HTTP API, and Web interface. I will not go into the details of the Orchestrator but will explore one of the features that can help us solve the errant GTID in a replication topology.

What are errant transactions?

Simply stated, they are transactions executed directly on a replica. Thus they only exist on a specific replica. This could result from a mistake (the application wrote to a replica instead of writing to the source) or by design (you need additional tables for reports).

What problem can errant transactions cause?

The major problem it causes during a planned change in a MySQL replication topology is that the transaction is not present in the binlog and hence …

A couple of days ago I was creating an index on the source and when I checked the replica side it was not replicated, so I just wanted to explain how the replication filter may increase the complexity of your DBA operations.

Replication occurs by reading events from the binary log of the source and then executing them on the replica. The events in the binary log are recorded in different formats, depending on the type of event. These formats are determined by the binary logging format used when the events were initially recorded on the source. The relationship between the binary logging formats and the terminology used during replication is as follows:

When using statement-based binary logging, the source writes SQL statements to the binary log. Replication of the source to the replica is performed by executing these SQL statements on the replica. This is known as statement-based replication (SBR), and it …

MySQL 8.0.23 introduces a new feature that makes replication possible from a source server that has been configured without Global Transaction Identifiers (GTIDs) to a replica server configured with GTIDs. This can be achieved by configuring replication channels to use the parameter ASSIGN_GTIDS_TO_ANONYMOUS_TRANSACTIONS with the CHANGE REPLICATION SOURCE command.…

Tweet Share

In our last blog post about the Automatic Asynchronous Replication Connection Failover feature which was released in MySQL 8.0.22, we showed you its usage and benefits. We now present here additional changes we added in MySQL 8.0.23 to further enhance this feature by making the receiver aware of the source’s group membership changes.…

Tweet Share

In one of our previous articles - Setting up Replication with various methods for MySQL 8 - we reviewed how to create a replica with multiple tools.
Now, it is time to perform the same action but with MySQL Shell.

The post MySQL SHELL – The new era first appeared on dasini.net - Diary of a MySQL experts.

In the world of the Databases, one of the most important value that we are all trying to achieve is High Availability. Not to loose our valuable data or in case one server fails to always have another to step in and take control.

So, it is critical to have along with our primary database, other identical instances, the replicas.

On this blog post, we will see the most famous ways to set up our replication.

The post Setting up Replication with various methods for MySQL 8 first appeared on dasini.net - Diary of a MySQL experts.

From MySQL 8.0.21 onwards, START GROUP_REPLICATION includes new options which allow a user to specify credentials to be used for distributed recovery. You can now pass credentials when invoking START GROUP_REPLICATION instead of setting them when configuring the group_replication_recovery channel.

START GROUP_REPLICATION command now has the options:

• USER: User name.

… Tweet Share

There is a new MySQL 8.0 release and it has some interesting replication features. The change log is available at the usual place, MySQL 8.0.21, but let me give you a brief summary.

• Binary Log Checksums Support for Group Replication (WL#9038).

… Tweet Share

In this post, we introduce a configuration option that controls whether replication channels allow the creation of tables without primary keys. This continues our recent work on replication security, where we allowed users to enforce privilege checks, and/or enforce row-based events.…

Tweet Share