This is a follow-up post in the MySQL Master Replication Crash Safety series. In the previous posts, we explored the consequences of reducing durability on masters (different data inconsistencies after an OS crash depending on replication type) and the performance boost associated with this configuration (benchmark results done on Google Cloud Platform / GCP). The consequences are summarised in
10 Older Entries »
This post is a sister post to MySQL Master Replication Crash Safety Part #5: making things faster without reducing durability. There is no introduction or conclusion to this post, only landing sections: reading this post without its context is not not recommended. You should start with the main post and come back here for more details.
And this Part #5 of the series has many sub-parts. So far,
Duration: 10 min
This tutorial will show you how to install Dynimize. We'll then use it to optimize a live MySQL process that's been running the Sysbench OLTP benchmark, obtaining a 46% increase in performance by applying Dynimize.
Part 1: Quickstart
Here's a quick overview of how to use Dynimize.
To install Dynimize, run the following commands.
wget https://dynimize.com/install -O install
wget https://dynimizecloud.com/install.sha256 -O install.sha256
sha256sum -c install.sha256; if [ $? -eq 0 ]; then sudo bash ./install -d; fi
Use your access token to start a subscription license for your host.
$ sudo dyni -license=start …[Read more]
This is a follow-up post in the MySQL Master Replication Crash Safety series. In the three previous posts, we explored the consequence of reducing durability on masters (including setting sync_binlog to a value different from 1). But so far, I only quickly presented why a DBA would run MySQL with such configuration. In this post, I present actual benchmark results. I also present a
This post is a sister post to MySQL Master Replication Crash Safety Part #4: benchmarks of high and low durability. There are no introduction or conclusion to this post, only landing sections: reading this post without its context is not recommended. You should start with the main post and come back here for more details.
My benchmark environment is composed of three vms in
I am currently running tests with sysbench and dbdeployer on a Google Cloud Platform Debian 9 instance. I ran into an interesting limit and lifting it was not straightforward. I hope that by sharing this, you can avoid losing too much time.
The benchmark I am using is the insert benchmark. I am able to run it with 2048 threads but I am not able to run it with 4096 threads (and yes, it makes
Sysbench has long been established as the de facto standard when it comes to benchmarking MySQL performance. Percona relies on it daily, and even Oracle uses it when blogging about new features in MySQL 8. Sysbench comes with several pre-defined benchmarking tests. These tests are written in an easy-to-understand scripting language called Lua. Some of these tests are called: oltp_read_write, oltp_point_select, tpcc, oltp_insert. There are over ten such scripts to emulate various behaviors found in standard OLTP applications.
But what if your application does not fit the pattern of traditional OLTP? How can you continue to utilize the power of load-testing, benchmarking, …[Read more]
Today I'd like to continue my review of public MySQL bug reports with a
list of some bugs I've subscribed to over last 3 weeks. It's
already long enough and includes nice cases to check and share.
Note that I usually subscribe to a bug either because it directly
affects me or customers I work with, or I consider it technically
interesting (so I mostly care about InnoDB, replication,
partitioning and optimizer bugs), or it's a "metabug" - a problem in the way public bug report
is handled by Oracle engineers. These are my interests related to
As usual, I start with the oldest bugs and try to mention bug reporters by name with links to their other reports whenever this may give something useful to a reader. I try …
This article is inspired by Percona blog post comparing MySQL 8.0 and
Percona Server 5.7 on IO-bound workload with Intel Optane
storage. There are several claims made by Vadim based on a single
test case, which is simply unfair. So, I'll try to clarify this
all based on more test results and more tech details..
But before we start, some intro :
InnoDB Parallel Flushing -- was introduced with MySQL 5.7 (as a single-thread flushing could no more follow), and implemented as dedicated parallel threads (cleaners) which are involved in background once per second to do LRU-driven flushing first (in case there is no more or too low amount of free pages) and then REDO-driven flushing (to flush …
Recently one of our customers wanted us to benchmark InnoDB, TokuDB and RocksDB on Intel(R) Xeon(R) Gold 6140 CPU (with 72 CPUs), nvme SSD (7 TB) and 530 GB RAM for performance. We have used Ubuntu xenial 16.04.4, Percona Server 5.7 (included storage engines- InnoDB/XtraDB, TokuDB and RocksDB) and Sysbench 1.0.15 with custom Lua scripts for this exercise, This benchmarking exercise included bulk INSERTS, WRITES, READS and READS-WRITES. We have tried our best to capture maximum information about the hardware infrastructure and copied / shared scripts we have used for benchmarking. This is not a paid / sponsored benchmarking effort by any of the software or hardware vendors, We will remain forever an vendor neutral and independent web-scale database infrastructure operations company with core expertise in performance, scalability, high availability and database reliability engineering. This benchmarking is …[Read more]
10 Older Entries »