How to achieve MySQL high availability, data protection & disaster recovery

This MySQL high availability and disaster recovery use case is based on a customer of ours who is a government-regulated lottery service consisting of a number of games of chance. Its mission is to fuel imagination – and fund education for all citizens of their state as it uses the proceeds of its activities to do so. Through its games, it has provided billions of dollars in scholarship and other such education funding for several decades.

What is the Challenge?

As is common for gambling and betting organisations, our customer faced a number of challenges and needed to have a solid infrastructure in place in order to provide its services satisfactorily.

This includes:

• Ensuring 24/7/365 availability of its online gaming platform
• Handling thousands of transactions quickly and while ensuring zero downtime …

This MySQL high availability and disaster recovery use case is based on a customer of ours who is a government-regulated lottery service and who needs 24x7x365 operations as well as be able to perform maintenance without any disruption to their public facing gaming website.

Tags:  Disaster Recovery High Availability MySQL use case Zero-Downtime

MySQL provides password-expiration capability, which enables database administrators to require that users reset their password.

The post MySQL Security – Password Expiration Policy first appeared on dasini.net - Diary of a MySQL expert.

Although MySQL is now more than two decades old, it continues to power some of the world’s largest internet applications. In this presentation, we’ll look at the history and evolution of distributed MySQL deployments. We’ll explore the original designs and the common architecture patterns still in use today. Finally, we’ll predict what the future has in store for us with the advent of the cloud and containers as the new operating environments for databases.

Please join Peter Zaitsev on Wednesday, April 29 at 11:00 am EDT for his webinar “Distributed MySQL Architectures – Past, Present, Future”.

Watch the Recording

If you can’t attend, sign up anyway and …

CVE-2020-10996

Percona XtraDB Cluster versions greater than 5.7.22-29.26 and less than 5.7.28-31.42.1 contained a script that handled SST transfers to nodes, this was inadvertently set to a static value due to an error in the bash script handling this process.

Applicability

Time based access to SST files is required in order to exploit this error, as sst files are ephemeral in nature the window in which an attacker with access to the filesystem can exploit this issue is limited.

In addition to the enablement of innodb at-rest encryption, which is not considered a GA feature at the time of writing.

Credits

Percona would like to thank Pavel Kasko for discovering this issue, and working to aid resolution.

More Information

• CVE-2020-10996
• …

Recently, I got access to the list of MySQL bug reports from bugs.mysql.com which someone crawled and stored in a MySQL database. I thought it would be interesting to see who the heroes are of MySQL bug reporting!

Top MySQL Bug Reporters Ever

select rank() over(order by count(*) desc) my_rank, count(*) cnt, reporter from bugs where reporter != "OCA Admin" and reporter != "[ name withheld ]" group by reporter order by cnt desc limit 20;
+---------+------+--------------------+
| my_rank | cnt  | reporter           |
+---------+------+--------------------+
|       1 | 1234 | Shane Bester       |
|       2 |  869 | Peter Gulutzan     |
|       3 |  818 | Daniël van Eeden   |
|       4 |  587 | Joerg Bruehe       |
|       5 |  572 | Philip Stoev       |
|       6 |  568 | Peter Laursen      |
|       7 |  564 | Roel Van de Paar   |
|       8 |  526 | Guilhem Bichot     |
|       9 |  524 | Jonathan …

Percona XtraDB Cluster 8.0 is in the final stretch before GA release and we have pre-release packages available for testing, and I wanted to see how Percona XtraDB Cluster 8.0 performs in CPU and IO-bound scenarios, like in my previous posts about MySQL Group Replication.

In this blog, I want to evaluate Percona XtraDB Cluster 8.0 scaling capabilities in I/O bound cases when we increase the number of nodes and increase user connections. The version I used is available here: …

CVE-2020-10997

Percona XtraDB backup >= 2.4.11 suffers an issue whereby the whole command line is captured and output to resulting backup file location, and where –history command line argument is passed this too is captured within the PERCONA_SCHEMA.xtrabackup_history table. In addition to the information being present within the process list and standard error output.

This issue is resolved in >= 2.4.20 and >= 8.0.11 .

Applicability

Access to backup files is required in order to exploit this error, protection of backup files and media is already a well known best-practise and we encourage our users to continue to follow this practise.

Authenticated access to the MySQL server is required to collect command line data where –history was used during backup.

Authenticated access to the Linux system on which PXB is being executed or access to the Process …

The other day on a call, a client asked me an interesting question.  We were discussing some testing they were doing in Amazon Relational Database Service (RDS).  The question came up “since RDS is managed, how can I prove to my security team that the data is actually encrypted?”  We’ve all read whitepapers and blogs that talk about encryption in the cloud, but it is something I’ve not needed to validate before.  Instead, I just enable encryption when I create an RDS instance and move along to the next steps of the setup. This discussion really got me thinking – what is the best way to enable and test encryption at rest in my RDS instance?

Encryption at Rest – MySQL Fundamentals

Before getting too far into the RDS specifics, I wanted to cover the basics of encryption at rest in MySQL.  There are essentially two ways to encrypt data at rest:

• Full disk encryption (filesystem/block …

Databases are complicated software made to handle the concurrent load while making specific guarantees about data consistency and availability. There are many scenarios which should be tested that can only happen under concurrent conditions.

Pstress is a probability-based open-source database testing tool designed to run in concurrency and to test if the database can recover when something goes wrong. It generates random transactions based on options provided by the user. With the right set of options, users can test features, regression, and crash recovery. It can create the concurrent load on a cluster or on a single server.

The tool is currently in beta, but it has already become very important within the testing pipeline for Percona. Pstress is widely used by Percona’s QA team during each phase of testing. It has …