Showing entries 1 to 10 of 27
10 Older Entries »
Displaying posts with tag: binary logs (reset)
The danger of no Primary Key when replicating in RBR (and a partial protection with MariaDB 10.1)

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

Many thanks Oracle for implementing RESET MASTER TO

MySQL 8.0.1 is out and it includes an implementation of my feature request (Bug #77438).  This extension to RESET MASTER allows to simplify master promotion with Binlog Servers.  Let's see how it works:

# mysql -N <<< "SHOW MASTER STATUS" binlog.027892 3006935 # mysql -N <<< "RESET MASTER TO 12345; DO sleep(rand()*10); SHOW MASTER STATUS" binlog.012345 92773 # mysql -N <<< "RESET MASTER TO

In place transparent compression of MySQL binary logs

Any DBA who has administered a busy master knows how fast the disk space occupied by binary logs may grow.  DBAs have no control on this: the growth depends on the workload, and the workload depends on many factors, e.g.:

- application changes (the applications start writing more due to code changes) - traffic changes (the peak season arrive, your workload doubles in size) - infrastructure changes (the devops add more servers) - business changes (new business flows adds to existing workload)
So either you have being thoughtful and have planned in advance for a large enough storage space (to handle the increase in number of binary logs), or,  sooner or later, you will face the usual dilemma - how many retention days dare you give up to accommodate for the binlog growth?
In my case, I was very thoughtful, but the boss didn't listen and gave me servers with very limited binlog storage space and, more important, …

[Read more]
Moving binary logs to a different filesystem without downtime

Another day at the office...

"Whoa, the write workload on our statistical cluster has  suddendly increased by 20% and the filesystem that holds the binary logs is no longer large enough".

Of course, I had warned the boss about this possibility when I received those servers with that tiny 250G filesystem for binlogs, but my red flag was just ignored as usual.

So here we are, presto I get this new shiny 600G LUN, but we need to stop the damn MySQL server in order to repoint the log_bin variable to the new storage area.

Dunno about you, but the idea of waking up at 2am to just perform a variable change is not something that makes me particularly happy. Not to mention the maintenance period that is needed around it....

So, I decided to investigate a bit about the possibilities to do such change without stopping the service.

As we all know, the log_bin …

[Read more]
Replication crash safety with MTS in MySQL 5.6 and 5.7: reality or illusion?

Reminder: MTS = Multi-Threaded Slave.

Update 2017-04-17: since the publication of this post, many things happened:

the procedure for fixing a crashed slave has been automated (Bug#77496) Bug#80103 as been closed at the same time as Bug#77496 but I still think there are unfixed things, see Bug#81840

End of update 2017-04-17.

I will be talking about parallel replication at FOSDEM in Brussel on

Binlog Servers for Simplifying Point in Time Recovery

A common way to implement point in time recovery capability is:

to regularly do a full backup of a database, and to save the binary logs of that database (or from its master if doing backups on a slave).

When point in time recovery is required you need to:

restore a backup, and apply the binary logs up to the point of recovery.

(Step # 2 and # b above are the ones that will be simplified

Abstracting Binlog Servers and MySQL Master Promotion without Reconfiguring all Slaves

Follow the link above to read my latest article on the Developer Blog.  It is about Binlog Servers and how to promote a slave as the new master without reconfiguring all slaves.

This is also a good opportunity to remind you of my next talks:

I’ll be giving a talk about Binlog

Log Buffer #434: A Carnival of the Vanities for DBAs

This Log Buffer Edition throws spotlight on some of the salient blog posts from Oracle, SQL Server and MySQL.


  • STANDARD date considerations in Oracle SQL and PL/SQL
  • My good friend, Oracle icon Karen Morton passed away.
  • Multiple invisible indexes on the same column in #Oracle 12c
  • Little things worth knowing: Data Guard Broker Setup changes in 12c …
[Read more]
Why base64-output=DECODE-ROWS does not print row events in MySQL binary logs

Lately I saw many cases when users specified option


  to print out a statement representation of row events in MySQL binary logs just to get nothing. Reason for this is obvious: option


  does not convert row events into its string representation, this is job of option


. But why users mix these two options so often? This blog post is result of my investigations.

There are already two great blog posts about printing row events on the Percona blog: “Debugging problems with row based replication” by Justin Swanhart and “ …

[Read more]
About the new warnings generated during 'PURGE BINARY LOGS' execution

In this blog, I will discuss about warnings that users might face if they are trying to purge active/in_use binary log which are introduced in MySQL-5.6.12/MySQL-5.7.2 releases.  Before jumping directly to that, I will be covering few basic things about PURGE BINARY LOGS command, about safe way to purge the binary logs on a replication forum. If you are good at basics on "PURGE BINARY LOGS" , you can choose to directly move to the section (at the end of the blog) where I was talking about these new warnings.

A binary log file contains “events” that describe database changes occurred on a MySQL Server (typically called Master) that enabled binary logging using --log-bin. On a Master server, the files that are related to binary logging are binary log files (files with binlog_base_name.6_digit serial_number) and a binary log index file (file with …

[Read more]
Showing entries 1 to 10 of 27
10 Older Entries »