Related resources Sharding MySQL with MySQL Fabric and ProxySQL MySQL Load Balancing with ProxySQL - an Overview How to set up read-write split in Galera Cluster using ProxySQL How ProxySQL adds Failover and Query Control to your MySQL Replication Setup Two Database Sharding Tools for MySQL
Having too large a (write) workload on a master is dangerous. If the master collapses and a …
[Read more]We’ve been having a problem with MySQL replication at work. Replicas periodically tend to fall behind and we couldn’t really figure out how to speed things up. It wasn’t about resources. The replicas have plenty of CPU and I/O available. We’re also using multithreaded replication (a.k.a. MTR) but most of the replication threads were idle.
One thing that we decided to try out was the new
LOGICAL_CLOCK parallelization policy introduced in
MySQL 5.7.2. Here’s what the MySQL reference manual says about
slave-parallel-type:
When using a multi-threaded slave
(slave_parallel_workers is greater than 0), this
option specifies the policy used to decide which transactions are
allowed to execute in parallel on the slave. The possible values
are:
Background
lm2 is my ordered key-value storage library. You can read my post about it here. There’s a lot to say about this little library, so this will be the first of a few posts about how lm2 works and why I chose to do things a certain way.
Caching
lm2 is essentially a linked list on disk. Everyone knows linked lists aren’t very fast. Searches take a ridiculously long time and require a lot of seeking. That’s why lm2 has a record cache, which stores a subset of the key-value records in memory. This cache really speeds up searches, but it’s used for much more. It’s also used for the write path. All writes in lm2 happen in memory before they’re durably recorded to disk.
There is only one level of caching at the moment. If you think about it, the architecture looks like a 2-level skip list.
A cache like …
[Read more]Today’s blog post is related again to MySQL Group Replication.
By default MySQL Group Replication runs in Single-Primary mode. And it’s the best option and the option you should use.
But sometimes it might happen that in very specific cases you would like to run you MGR Cluster in Multi-Primary mode: writing simultaneously on all the nodes member of the Group.
It’s of course feasible but you need to make some extra verification as not all workload are compatible with this behavior of the cluster.
Requirements
The requirements are the same as those for using MGR in Single-Primary mode:
This post discusses enabling and disabling jemalloc on Percona Server for MySQL.
The benefits of jemalloc versus glibc for use with MySQL have been widely discussed. With jemalloc (along with Transparent Huge Pages disabled) you have less memory fragmentation, and thus more efficient resource management of the available server memory.
For standard installations of Percona Server 5.6+ (releases starting with 5.6.19-67.0), the only thing needed to …
[Read more]Hi all,
Fosdem’s organization relocated the MySQL & Friends Devroom from H.1308 to H.1309 (Van Rijn).
It’s the same building, just the door next to it.
MySQL will also have a stand in the H building. Don’t hesitate to visit it (I’ve heard there will be some Sakila Dolphins !)
Related resources Schema Changes for MySQL Replication & Galera Cluster Database Cluster Management - Manual vs Automation via ClusterControl Migrating to MySQL 5.7 - The Database Upgrade Guide
In the previous blog post, we discussed how gh-ost works internally and how it compares to Percona’s pt-online-schema-change. Today we’d like to focus on operations - how can we test a schema change with gh-ost to verify …
[Read more]
The mysql client is a tool which I use every day
as a DBA. I think it's a great tool. When I used a client of
several other SQL and NoSQL databases I was quickly reminded of
all the features of the mysql client. Note that psql (PostgreSQL
client) is also very nice.
Some other interesting things about the mysql client: It is build
from the same mysql-server repository as MySQL Server. The source
is in client/mysql.cc. In addition to the server
version it also reports 14.14 as its version. The previous
version (14.13) was around the time of MySQL 5.1, so this version
is mostly meaningless.
If you start it it identifies itself as "MySQL monitor", not to
be confused with MySQL Enterprise Monitor.
The version of the client is not tightly coupled with the …
It's time to summarize the year of 2016. As a kind of a weird
summary, in this post I'd like to share a list of MySQL bug
reports I've created in 2016 that are still remaining "Verified"
today:
The MyRocks community grew in 2016 with significant contributions
from early evaluators. I appreciate their help and have been busy
documenting the problems that they reported. I look forward to
more contributions in 2017.
MariaDB Corporation and Percona announced plans to include
MyRocks in their distributions. You will be able to get MyRocks
with expert support. Equally big have been the contributions from
Sergey Pertunya to MyRocks.
The MySQL team at Alibaba reported poor performance from range
scans with sysbench. The problem was memory system contention on
a performance counter and the fix made long range scans 2X faster on concurrent workloads.
I have been using sysbench more and …
