Showing entries 1 to 10 of 45352
10 Older Entries »
The DuckDB MySQL engine at 500 GB

We ran DuckDB MySQL storage engine at scale factor 500. It is around 500 GB of raw TPC-H, three billion lineitem rows  on an 80-core server with 187 GB of RAM. Three engines on the same box: InnoDB, our MySQL+DuckDB engine, and plain DuckDB as the reference.

Here is what came out. InnoDB finished 18 of the 22 queries and spent more than 28 hours of query time on them. Four never finished. Our engine ran all 22 in about three minutes. It loaded the data 25 times faster than InnoDB, and it used 5 times less disk. On the queries it stays close to plain DuckDB, and on a few it is ahead.

It’s still an experiment, not production software. Code and the benchmark harness are on GitHub under GPLv2: https://github.com/Percona-Lab/ducksdb-mysql-engine.

The machine, and how we ran it

  • One server, 80 cores, 187.5 GB RAM.
[Read more]
MySQL 8.0.17 GTID Crash Safety Improvement

I have known for some times that there is an interesting improvement in MySQL 8.0.17 regarding GTID Crash Safety, but I have not had the time nor the need to look into it before.  When writing my last post (Understanding MySQL Replication "fatal error 1236": [...]), I saw something interesting related to this, and it is now time to cover this on my blog. From my point of view, this change is

Recovery Optimization for Large MySQL Transactions

This article is also available in Chinese: 中文版. Browse all English articles.

Have you ever run into a mysqld process that has been starting for a long time and still won’t come up? When that happens, you can use perf top to check what the MySQL process is mainly doing. If what you see looks like the figure below — the MySQL main thread (the one starting from mysqld_main) spending the vast majority of its time rolling back transactions — then you are very likely hitting a large-transaction rollback.

The most common way to get here is a large transaction that fills up the disk while writing its binlog, crashing the instance. The largest binlog file I have run into was over 114GB. Since the Binlog Cache’s …

[Read more]
Understanding MySQL Replication "fatal error 1236": "Replica has more GTIDs than the source has, using the source's SERVER_UUID"

This MySQL replication error — fatal error 1236 / Replica has more GTIDs than the source has, using the source's SERVER_UUID — shows the importance of thinking before acting.  I am glad a non-DBA Colleague asked me about it, because if he had restarted replication, it would have caused a much bigger mess. Often, we are tempted — or pushed — to just restart things

MySQL Development as it Happens – Innovating Together

Henrik IngoMySQL Community Architect In May we hosted the first MySQL Contributor Summit 2026. We arrange such Summits every quarter, and it’s a forum where contributors come together and make proposals, and then discuss them, on what they wish to work on, or see someone else work on, in future MySQL versions.  All of the presentations are now […]

Where can you find MySQL from August through October 2026? 

The MySQL Community team will continue to be active across conferences, user group meetups, open source events, and regional community activities throughout August, September, and October 2026.  While some of our August events were featured in our previous event update, we’ve included them here again with the latest information. Whether you’re interested in learning about MySQL 9.7 LTS, exploring the latest features in […]

MySQL July 2026 GA Releases Now Available

The July 2026 MySQL releases are now available, including: MySQL 26.7.0 is the first generally available Innovation release following MySQL 9.7 LTS and the first MySQL release to use the new calendar-versioning model. MySQL 9.7.2 and MySQL 8.4.11 continue the quarterly maintenance cadence for the current MySQL Long-Term Support release lines. A new calendar-versioning model […]

Stored Procedures memory consumption in Percona Server for MySQL

1. What it is about

This investigation began as a performance comparison for different memory allocators. However, during benchmarking, I discovered unexpected effects deserving a more detailed explanation. I hope you find these findings both interesting and useful.

Imagine you need to set up a MySQL database server. Every detail is planned: the operating system, the CPU architecture, the number of cores, the amount of RAM, the storage capacity and speed. On paper the hardware looks like it can handle the workload. But in reality, things rarely go exactly as planned. So, conducting a thorough stress test is the next thing to do.

 

2. Realities of stress testing

You configure your MySQL server setting the innodb_buffer_pool_size to 70-80% of your available RAM. This creates a large fast buffer for your data and indexes, reducing the need for slower disk input/output.

After …

[Read more]
Summary of MySQL Public Discussion #5: The Contributor Experience

The fifth MySQL Public Discussion as part of our Community Engagement plan. The plan includes accelerating innovation in MySQL Community Edition, increasing community contributions and expanding the MySQL ecosystem overall. This session was focused on the contributor experience and the ongoing work to make contributing to MySQL more transparent and accessible. The session covered MySQL […]

MySQL Best Practice : not using date / time types, nor ENUM

Today, I was reminded of a MySQL Best Practice, probably generalizable to all databases : using simple types, not complex types.  Such complex types to avoid include the date and time data types (including TIMESTAMP) and ENUM.  Let's see why.

A little history about this, Baron Schwartz, a MySQL Legend who is not involved in the community anymore, compared using the TIMESTAMP type to

Showing entries 1 to 10 of 45352
10 Older Entries »