We recently helped a social media management platform improve its security and performance.

The social media platform supports social network integrations for Twitter, Facebook, Instagram, LinkedIn and YouTube, and has more than 15 million users. The company needed to ensure maximum security and performance for its authentication processes by reducing the hours and errors associated with manual administration.

These improvements would allow the organization to not only minimize downtime and expand the feature set available to its developers, but would also ensure the company’s compliance with Europe’s new General Data Protection Regulation (GDPR). The challenge was automating its database user management and authentication processes, which required knowledge of MySQL security and DevOps environments.

Pythian’s experts have deep knowledge of MySQL security and DevOps-structured environments, and were able to develop …

This is a quick blog demonstrating a couple backup Restore uses cases within a MySQL InnoDB Cluster 8.0 setup.  The backup used was completed in a previous blog (part 2 in this series) with the  MySQL Enterprise Backup 8.0 utility.  I’ll then use that backup to build an additional member to add to the cluster. This blog… Read More »

Join Percona CEO Peter Zaitsev at AWS re:Invent as he presents MySQL High Availability and Disaster Recovery on Tuesday, November 27, 2018, in the Bellagio Resort, Level 1, Gaugin 2 at 1:45 PM.

In this hour-long session, Peter describes the differences between high availability (HA) and disaster recovery (DR), and then moves through scenarios detailing how each is handled manually and in Amazon RDS.

He’ll review the pros and cons of managing HA and DR in the traditional database environment as well in the cloud. Having full control of these areas is daunting, and Amazon RDS makes meeting these needs easier and more efficient.

Regardless of which path you choose, it is necessary that you monitor your …

Introduction  To upgrade MySQL versions  we can use below method:-

1. INPLACE Upgrade :- It involves shutting down MySQL 5.7  server,replacing the old binaries  with MySQL 8.0 binaries and then starting the MySQL 8.0 server on the old data directory. 
2. LOGICAL Upgrade:- It involves exporting SQL from MySQL 5.7 version using backup utility such as mysqldump or mysqlpump , installing the MySQL 8.0 binaries and then applying the SQL to the new version.

Before start upgrading the MySQL versions it is recommended to have deeper analysis by visiting MySQL Documentation page. Upgrading MySQL :- https://dev.mysql.com/doc/refman/8.0/en/upgrading.html
What is MySQL Upgrade Checker? Utility to check MySQL 5.7 server …

In this blog post, I’ll highlight new Backup Support in the MySQL Enterprise Backup 8.0 utility for Group Replication and InnoDB Cluster. This will also include usage of the MySQL login-path utility for accessing credentials for the backup process as highlighted in this other blog post on Devops ideas with MySQL and Scripting for Binary Log… Read More »

Features and capabilities continue to arrive in MySQL 8.0, most recently noted in the GA release of MySQL 8.0.13.  The mysql-shell 8.0.12 release introduced a number of things, an important part was a cross-platform mysql-shell secure password handling facility.  The MySQL Login-paths are a part of that security focus.  Here we will look at where InnoDB Cluster 8.0,… Read More »

Over the last year, I have been pursuing a part time hobby project exploring ways to squeeze as much data as possible in MySQL. As you will see, there are quite a few different ways. Of course things like compression ratio matters a lot but, other items like performance of inserts, selects and updates, along with the total amount of bytes written are also important. When you start combining all the possibilities, you end up with a large set of compression options and, of course, I am surely missing a ton. This project has been a great learning opportunity and I hope you’ll enjoy reading about my results. Given the volume of results, I’ll have to write a series of posts. This post is the first of the series. I also have to mention that some of my work overlaps work done by one of my colleague, Yura Sorokin, in a …

This year I participated for the first time to the DOAG, the conference which takes place in November in Nuremberg. Here some key words about this event: Oracle and other technologies, 2000 visitors, more than 400 sessions, more than 800 abstracts sent, exhibitors…
And for me everything started when in June I decided to send an abstract for a MySQL session.

Preparation

I’ve been working on MySQL for several years. At the beginning of this year, I started testing the new 8.0 version. We live in an age where security is more important than ever, GDPR and other regulations force us to review some subjects such as privacy and data policies. MySQL put in place lots of improvements regarding security in this last version.
So my session proposal for the DOAG was the following one:

MySQL 8.0 Community – Ready for GDPR ?
One of the most topical subject today is …

As per the documentation, pt-table-checksum is a tool to perform online replication consistency checks by executing checksum queries on the master, which produces different results on replicas that are inconsistent with the master.

The master and each slave insert checksums into the percona.checksums table, and these are later compared for differences. It’s fairly obvious that the checksums need to be determined independently on each node, and so these inserts must be replicated as STATEMENT and not ROW. Otherwise, the slaves would just insert the same checksum as the master and not calculate it independently.

The tool only requires

binlog_format=STATEMENT

  for its own session. It sets this itself on the master, but will error if this isn’t already set on each slave node. The …

As you know, MySQL InnoDB Cluster is a High Availability solution for MySQL. However more and more people are trying to use it as a Disaster Recovery solution with 2 data centers. Natively, this is not yet supported. But it’s already possible to realize such setup if we agree with the following points:

•  a human interaction is required in case of Disaster Recovery which, by my own experience, is often acceptable
• a human interaction is required if the any Primary-Master acting as asynchronous slave leaves its group  (crash, network problem, …) or becomes secondary

These are not big constraints and it’s relatively easily to deal with them.

The Architecture

The situation is as follow:

• 2 data centers (one active, one inactive, only used for disaster recovery)
• 2 MySQL InnoDB Clusters (one in each DC)
• 3 members in each …