How to use binary logging in MySQL


Hey there! So, you want to learn how to use binary logging in MySQL, huh? Well, you’ve come to the right place! In this article, we’ll take a deep dive into the world of binary logging, exploring why it’s important and how you can use it to your advantage.

Before we start, let’s set the stage with a quick overview of binary logging. Binary logs are a series of log files that record events that modify the data or structure of your MySQL database. They are useful for many purposes, such as replication, backups, and even auditing. So, buckle up, and let’s get rolling!

Table of Contents

  1. Activating Binary Logging in MySQL
  2. Configuring Binary Logging Options
  3. Using Binary Log Files for Replication
  4. Restoring Data from Binary Log Files
  5. Analyzing and Auditing with mysqlbinlog
  6. Managing Binary Log Files
  7. Troubleshooting Common Binary Logging Issues
  8. Activating Binary Logging in MySQL

Activating Binary Logging in MySQL

First things first, let’s get binary logging up and running. To enable binary logging in MySQL, you’ll need to make a few changes to your MySQL configuration file (my.cnf or my.ini, depending on your system). Here’s what you need to do:

Add the log_bin directive

Open your MySQL configuration file in your favorite text editor and add the following line:

log_bin = mysql-bin

This line tells MySQL to enable binary logging and use the prefix “mysql-bin” for the log files it generates. Feel free to change the prefix if you want!

Set the server_id

Next, you’ll need to set the server_id option. This is especially important if you plan on using replication:

server_id = 1

Just make sure each MySQL server in your replication setup has a unique server_id.

Restart MySQL

Save your changes and restart the MySQL server. Binary logging should now be enabled!

Configuring Binary Logging Options

Now that binary logging is activated, let’s tweak some options to get the most out of it. Here are some useful settings to consider:


This option lets you specify the full path and prefix for your binary log files:

log_bin_basename = /var/lib/mysql/my_bin_logs/mysql-bin


To prevent binary logs from piling up and eating your disk space, set a log expiration period:

expire_logs_days = 7

This example will automatically remove logs older than 7 days.


Choose the format of your binary logs: STATEMENT, ROW, or MIXED. ROW is the default and recommended for most use cases:

binlog_format = ROW

Using Binary Log Files for Replication

Binary logs play a key role in MySQL replication. The basic idea is that the master server writes events to its binary logs, and slave servers read these logs to replicate the changes.

To set up replication, follow these steps:

Configure the master server

On the master server, enable binary logging and set a unique server_id, as explained earlier.

Grant replication privileges

Create a user on the master server with REPLICATION SLAVE privileges:

CREATE USER 'replica_user'@'%' IDENTIFIED BY 'your_password';
GRANT REPLICATION SLAVE ON *.* TO 'replica_user'@'%';

3.3. Configure the slave server

On the slave server, set a unique server_id and add the following configuration options:

relay_log = /var/lib/mysql/relay-bin
read_only = 1

The relay_log option specifies the path and prefix for relay log files, which the slave server uses to store events before applying them. The read_only option ensures that no data changes can be made directly on the slave server.

Set up the replication relationship

On the slave server, execute the following command to establish the replication relationship with the master server:

  MASTER_HOST = 'master_ip_or_hostname',
  MASTER_USER = 'replica_user',
  MASTER_PASSWORD = 'your_password',
  MASTER_LOG_FILE = 'mysql-bin.000001',

Replace the MASTER_HOST, MASTER_USER, and MASTER_PASSWORD placeholders with the appropriate values.

Start replication

Finally, start the replication process on the slave server:


To verify that replication is working, use the SHOW SLAVE STATUS command and check that the Slave_IO_Running and Slave_SQL_Running columns show “Yes.”

Restoring Data from Binary Log Files

Binary logs can be a lifesaver when you need to recover lost data. To restore data from binary logs, you’ll use the mysqlbinlog tool to generate SQL statements and then execute them.

Here’s an example of how to restore data:

Identify the relevant log files

First, find the log files containing the events you want to restore. You can use the mysqlbinlog tool to inspect the contents of binary log files:

mysqlbinlog mysql-bin.000001

Extract the SQL statements

Once you’ve identified the log files, use mysqlbinlog to extract the SQL statements you want to restore. For example, to extract all statements after a specific datetime, use:

mysqlbinlog --start-datetime="2023-03-19 10:00:00" mysql-bin.000001 > restore.sql

Execute the SQL statements

Finally, apply the extracted SQL statements to your MySQL server:

mysql -u your_user -p your_database < restore.sql

Analyzing and Auditing with mysqlbinlog

The mysqlbinlog tool can also be used for analyzing and auditing purposes. Here are a few examples:

Filter by database or table

To display events related to a specific database or table, use the –database or –table options:

mysqlbinlog --database=mydatabase mysql-bin.000001
mysqlbinlog --table=mytable mysql-bin.000001

Filter by event type

To display only specific event types, such as table creation or updates, use the –base64-output and –result-file options:

mysqlbinlog --base64-output=DECODE-ROWS --result-file=output.txt mysql-bin.000001

Then, use a text editor or grep to search for specific event types in the output file.

Managing Binary Log Files

Binary log files can grow rapidly, so it’s essential to manage them effectively. Here are some tips:

Rotate log files manually

To rotate binary log files manually, use the FLUSH LOGS command:


This command creates a new binary log file and closes the current one.

Monitor log file size

Keep an eye on the size of your binary log files, and rotate them when necessary. You can use the SHOW BINARY LOGS command to check the file sizes:


Troubleshooting Common Binary Logging Issues

Even with the best configuration, you might encounter some issues with binary logging. Here are some common problems and their solutions:

Insufficient disk space

Binary log files can consume a lot of disk space, especially on busy servers. To avoid running out of space, consider:

  • Increasing the value of expire_logs_days to remove older log files more frequently.
  • Rotating log files manually or setting up a scheduled task to do it automatically.
  • Monitoring disk space usage and taking action when needed.

Slow performance due to binary logging

Binary logging can cause performance overhead, especially with the ROW format. To mitigate this, consider:

  • Changing the binlog_format to MIXED or STATEMENT, which may reduce the overhead, but be aware of their limitations and potential issues.
  • Optimizing your storage subsystem for write performance, such as using SSDs or RAID configurations.
  • Reducing the frequency of events being logged by tuning your application or database settings.

Replication lag

If you’re using binary logs for replication and notice that the slave server is falling behind, try the following:

  • Check for hardware bottlenecks, such as slow disk I/O or network latency.
  • Increase the value of slave_parallel_workers on the slave server to allow for parallel replication.
  • Optimize your database schema, queries, and indexes to reduce the replication workload.


Phew! We’ve covered a lot in this article. By now, you should have a good understanding of how to use binary logging in MySQL for replication, backups, and auditing purposes. Remember to keep an eye on your log files, manage them efficiently, and troubleshoot any issues that may arise.

With a solid grasp of binary logging under your belt, you’re well on your way to mastering the ins and outs of MySQL.

Related Articles