Well, since working with outdated clusters and upgrade paths that quickly become obsolete, as in my last post, Migrating/importing NDB to Cluster Manager w/ version upgrade. , I wanted to share that we can also use Cluster Manager, mcm, to upgrade NDB Cluster from 7.3 directly to 7.5. So we can start using the mcm new features like autotune that help guide us towards some Cluster tuning, or 7.5 new features like READ_BACKUP or FULLY_REPLICATED tables. …[Read more]
10 Older Entries »
TL;DR: unless you know what you are doing, you should always have a primary key on your tables when replicating in RBR (and maybe even all the time).
TL;DR2: MariaDB 10.1 has an interesting way to protect against missing a primary key (innodb_force_primary_key) but it could be improved.
A few weeks ago, I was called off hours because replication delay on all the slaves from a replication chain
In this post I’ll answer questions I received in my Wednesday, July 19, 2017, webinar Learning MySQL 5.7!
First, thank you all who attended the webinar. The link to the slides and the webinar recording can be found here.
I received a number of interesting questions in the webinar that I’ve followed up with below.
Would there be a big difference on passing from 5.1 to 5.6 before going to 5.7 or, at this point, would it be roughly the same?
The biggest risk of jumping between versions, in this case 5.1 to 5.6, is reverting in case of problems. Rollbacks don’t happen often, but they do happen and you have to make …[Read more]
In my last post about big MySQL deployments, I am quickly mentioning that InnoDB compression is allowing dividing disk usage by about 4.3 on a 200+ TiB dataset. In this post, I will give more information about this specific use case of InnoDB table compression and I will share some statistics and learnings on this system and subject. Note that I am not covering InnoDB page compression which is
I’ll be covering this subject (and others) in my webinar Learning MySQL 5.7 on Wednesday, July 19, 2017.
We’ve been doing upgrades for quite a while here are Percona, and we try to optimize, standardize and improve this process to save time. When upgrading to MySQL 5.7, more often than not you need to run REPAIR or ALTER via mysql_upgrade to a number of MySQL tables. Sometimes a few hundred, sometimes hundreds of thousands.
One way to cut some time from testing or executing mysql_upgrade is to combine it with mysqlcheck. This identifies tables that need to be rebuilt or repaired. The first …[Read more]
This is a story about why it's a good idea to test and verify the
behavior of new software releases, even if the change log says
that a particular bug was already fixed.
Background MySQL 5.6 and 5.7 both support the following CREATE USER syntax:
CREATE USER 'user'@'host'
IDENTIFIED BY 'password';
This syntax create a user with the default authentication plugin
(mysql_native_password unless configured otherwise) and the
password provided. The IDENTIFIED BY syntax is also supported for
Both major versions also support the following syntax:
CREATE USER 'user'@'host'
IDENTIFIED WITH mysql_native_password AS 'hash_string';
The password hash for "passw0rd" is "*74B1C21ACE0C2D6B0678A5E503D2A60E8F9651A3", you might then expect …[Read more]
In this part of the "quick look" series, I evaluate the
performance of DDL operations in Amazon Aurora and vanilla MySQL.
I'll use a few examples to demonstrate how fast the DDLs run and
what impact they can have on regular workload. I'll also take the
Aurora's Fast DDL feature for a spin.
Introduction DDL operations are a well-known source of pain in MySQL-based environments. They are not very fast, they're not fully online (non-blocking), and they're difficult to run on top of regular workload without serious performance degradation. MySQL has not seen much improvement in this area for quite some time, which is we have tools such as pt-online-schema-change, now considered to be an industry standard rather than a workaround.
Amazon Aurora tries to shake things up a little bit with the Fast DDL feature, which (as of this writing) allows you to add a nullable column at the end of a table nearly instantaneously. You can …
This post was originally published on the MySQL Support Team Blog at https://blogs.oracle.com/mysqlsupport/entry/innodb_locks_analysis_why_is on 14 April 2017.
Consider the scenario that you execute a query. You expect it to be fast – typically subsecond – but now it take not return until after 50 seconds (innodb_lock_wait_timeout seconds) and then it returns with an error:
mysql> UPDATE world.City SET Population = Population + 999 WHERE ID = 130; ERROR 1205 (HY000): Lock wait timeout exceeded; try restarting transaction
You continue to investigate the issue using the sys.innodb_lock_waits view or the underlying Information Schema tables (INNODB_TRX, INNODB_LOCKS and INNODB_LOCK_WAITS).
Note: The above Information Schema tables with lock and lock waits information have been moved to the Performance Schema in 8.0 as the data_locks and data_lock_waits tables. The sys schema view however …[Read more]
Yes, another post about my talks at Percona Live Santa Clara: I obviously still have things to share. This time, I will focus on my parallel replication talks by giving a short preview.
I have two parallel replication talks at Percona Live:
MySQL/MariaDB Parallel Replication: inventory, use cases and limitations (Wednesday talk) MySQL Parallel Replication: all the 5.7 (and some of the 8.0)
In a previous post, I listed all the Booking.com talks at Percona Live. In this post, I will give more details about my talks.
As a reminder, the list of my talks is the following:
Monitoring Booking.com without looking at MySQL (Thursday keynote) The two little bugs that almost brought down Booking.com (Tuesday Lightning Talk) MySQL/MariaDB Parallel Replication: inventory, use cases and
10 Older Entries »