Showing entries 1 to 10 of 181
10 Older Entries »
Displaying posts with tag: mysql replication (reset)
START GROUP_REPLICATION can now take recovery credentials as parameters

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

MySQL 8.0.21 Replication Enhancements

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

Enforce Primary Key constraints on Replication

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

MySQL 8.0.20 Replication Enhancements

We have just released MySQL 8.0.20. And it has some interesting replication enhancements. In particular one big and exciting feature: binary log compression. Here is the list of things in this release:

  • Binary Log Compression (WL#3549). This work done by Luís Soares implements binary log compression, making use of the popular compression algorithm ZSTD.

Tweet Share

Use Case: Geo-distributed Multi-master MySQL for Telco Providers

This is our third ‘multi-master MySQL’ blog in our Continuent MySQL Use Case series, with a focus on Telco providers. This blog concludes our multi-master MySQL mini-series along with the following two blogs:

As per our initial multi-master MySQL use case blog, multi-master replication for MySQL typically means that a user can write to any master node knowing that the write will be eventually consistent for …

[Read more]
Use Case: Geo-distributed Multi-master MySQL for Financial Services SaaS Providers

For this next ‘multi-master MySQL’ blog in our Continuent MySQL Use Case series, we’re focusing on Financial Services Saas providers.

Often referred to as the number one open source database in the cloud, and a leading SaaS database, MySQL enables SaaS vendors to be competitive because it provides cost-effective data security and privacy, performance, and availability amongst other things, which are of particular importance for a SaaS business.

As per our previous multi-master MySQL use case blog (for e-commerce sites), multi-master replication for MySQL typically means that a user can write to any master node knowing that the write will be eventually consistent for all nodes in the cluster; unlike regular MySQL replication, where writes have to be applied to the sole master to ensure that it will be replicated to …

[Read more]
Use Case: Multi-master MySQL for e-Commerce Sites

For this next blog in our Continuent MySQL Use Case series, we’re diving into a sub-series on the topic of ‘multi-master MySQL’.

We’ll cover three (3) multi-master MySQL use cases as part of this sub-series focusing first on e-commerce to start with, and then following up with use cases from financial services and telecommunications.

Multi-master replication for MySQL typically means that a user can write to any master node knowing that the write will be eventually consistent for all nodes in the cluster; unlike regular MySQL replication, where writes have to be applied to the sole master to ensure that it will be synched to all the slaves.

The First Multi-master Customer

The first Continuent multi-master customer is a leading fashion e-commerce company with sites servicing customers across the globe.

More specifically, it has four multi-brand online stores and several online flagship stores …

[Read more]
Preserving commit order on replicas with binary log disabled

MySQL 8.0.19 introduces Binlogless replicas with commit ordering which means you can deploy asynchronous replicas without binary logs enabled, and commit transactions in the same order they are replicated in. Yes, you can disable binlog (skip-log-bin) and the logging of changes done by the applier (log-slave-updates=FALSE) while at the same preserve commit order (slave-preserve-commit-order=TRUE).…

Tweet Share

Restrict MySQL replication to row based events

In a follow-up to the work presented on MySQL 8.0.18  where we introduced privilege checks for slave applier threads, in this post we present a new feature to further increase your ability to securely replicate your data: you can now restrict replication streams to row based events only.…

Tweet Share

MySQL 8.0.19 Replication Enhancements

Here comes another MySQL release, and together with it, a set of new replication features. As usual, we would like to summarize them. And, also as usual, follow up blogs will provide further details.

  • Configure Replication Applier to Require Row-based Replication only.

Tweet Share

Showing entries 1 to 10 of 181
10 Older Entries »