The MariaDB project is pleased to announce the immediate availability of MariaDB 10.1.24, and MariaDB Connector/C 2.3.3. See the release notes and changelogs for details. Download MariaDB 10.1.24 Release Notes Changelog What is MariaDB 10.1? MariaDB APT and YUM Repository Configuration Generator Download MariaDB Connector/C 2.3.3 Release Notes Changelog About MariaDB Connector/C Thanks, and enjoy […]

The post MariaDB 10.1.24 and Connector/C 2.3.3 now available appeared first on MariaDB.org.

In this blog post, we’ll look at how Percona XtraDB Cluster maintenance mode uses ProxySQL to take cluster nodes offline without impacting workloads.

Percona XtraDB Cluster Maintenance Mode

Since Percona XtraDB Cluster offers a high availability solution, it must consider a data flow where a cluster node gets taken down for maintenance (through isolation from a cluster or complete shutdown).

Percona XtraDB Cluster facilitated this by introducing a maintenance mode. Percona XtraDB Cluster maintenance mode reduces the number of abrupt workload failures if a node is taken down using ProxySQL (as a load balancer).

The central idea is delaying the core node action …

MySQL InnoDB Cluster (or only Group Replication) becomes more and more popular. This solution doesn’t attract only experts anymore. On social medias, forums and other discussions, people are asking me what it the best way to migrate a running environment using traditional asynchronous replication [Master -> Slave(s)] to InnoDB Cluster.

The following procedure is what I’m actually recommending. These steps have for objective to reduce the downtime to the minimum for the database service.

We can divide the procedure in 9 steps:

1. the current situation
2. preparing the future cluster
3. data transfert
4. replication from current system
5. creation of the cluster with a single instance
6. adding instances to the cluster
7. configure the router
8. test phase
9. pointing the application to the new solution

…

Hello again everybody.

Well, I promised it a couple of weeks ago, and I’m sorry it has been so long (I’ve been working on other fun stuff in addition to this). But I’m pleased to say that we now have a fully working applier that takes data from an incoming THL stream, whether that is Oracle or MySQL, and converts that into a JSON document and message for distribution over a Kafka topic.

Currently, the configuration is organised with the following parameters:

• The topic name is set according to the incoming schema and table. You can optionally add a prefix. So, for example, if you have a table ‘invoices’ in the schema ‘sales’, your Kafka topic will be sales_invoices, or if you’ve added a prefix, ‘myprefix_schema_table’.
• Data is marshalled into a JSON document as part of the message, and the structure is to have a bunch of metadata and then an embedded record. You’ll see an …

Hello again everybody.

Well, I promised it a couple of weeks ago, and I’m sorry it has been so long (I’ve been working on other fun stuff in addition to this). But I’m pleased to say that we now have a fully working applier that takes data from an incoming THL stream, whether that is Oracle or MySQL, and converts that into a JSON document and message for distribution over a Kafka topic.

Currently, the configuration is organised with the following parameters:

• The topic name is set according to the incoming schema and table. You can optionally add a prefix. So, for example, if you have a table ‘invoices’ in the schema ‘sales’, your Kafka topic will be sales_invoices, or if you’ve added a prefix, ‘myprefix_schema_table’.
• Data is marshalled into a JSON document as part of the message, and the structure is to have a bunch of metadata and then an embedded record. You’ll see an …

If you like to read (a lot) and you're considering to migrate your database workloads to AWS, this might be something for you. Nearly 75 pages of ideas for planning, executing, and troubleshooting database migrations to Amazon Aurora.

I recently published an Aurora Migration Handbook in the form of an AWS Whitepaper. The document can be downloaded from here:

https://d0.awsstatic.com/whitepapers/Migration/amazon-aurora-migration-handbook.pdf

Happy reading!

This post tries to answer some of the most popular questions I receive from customers, regarding the best practices for database proof-of-concept and migration projects.

Notes

• This document discusses best practices for database proof-of-concept projects with MySQL-compatible databases. I’ll be making some references to products offered by Amazon Web Services, because it’s the service environment I work with on a daily basis. However, the guide is written in a generic enough way that you can most likely use it for any database POC, regardless of the database engine (MySQL or not) and provider (AWS or not). I’ll often use the terms “new database” or “new product” to refer to the product you’re evaluating.
• Topics and challenges mentioned in the below recommendations do overlap. The review of a POC plan is not considered complete unless recommendations from all areas are considered and applied …

Percona announces the GA release of Percona XtraBackup 2.4.7-2 on May 29, 2017. You can download it from our download site and apt and yum repositories.

Percona XtraBackup enables MySQL backups without blocking user queries, making it ideal for companies with large data sets and mission-critical applications that cannot tolerate long periods of downtime. Offered free as an open source solution, Percona …

Please join Percona’s solution engineer, Dimitri Vanoverbeke as he presents Online MySQL Backups with Percona XtraBackup on Wednesday, May 31, 2017 at 7:00 am PDT / 10:00 am EDT (UTC-7).

Register Now

Percona XtraBackup is a free, open source, complete online backup solution for all versions of Percona Server, MySQL® and MariaDB®. Percona XtraBackup provides:

• Fast and reliable backups
• Uninterrupted transaction processing during backups
• Savings on disk space and network bandwidth with better compression
• Automatic backup …

As Rene wrote on the ProxySQL blog yesterday:

Although MySQL Query Cache was meant to improve performance, it has serious scalability issues and it can easily become a severe bottleneck.

This is indeed something we have observed in the MySQL team for a while.…