Does MySQL binary logging capture all databases when no specific databases are configured?

Other Questions MySQL
1

I’m configuring database replication for a server that hosts multiple client databases. New databases get added regularly, so I’m wondering about the best approach for binary logging configuration.

Currently I’m thinking about this setup in my configuration file:

log-bin-ignore-db = mysql
log-bin-ignore-db = information_schema

Instead of explicitly listing every database like this:

log-bin-do-db = client_db_1
log-bin-do-db = client_db_2
log-bin-do-db = client_db_3

Will this approach automatically log all databases except the ones I specifically ignore? I want to make sure new databases get replicated without manually updating the config each time.

I noticed that when I remove the explicit database list, the binary log position changes when I modify data, but my slave server doesn’t seem to pick up the changes. Am I missing something in my replication setup?

2

Yes, you are correct that MySQL binary logging captures all databases by default unless specified otherwise. Your configuration to ignore specific databases using log-bin-ignore-db should effectively allow new databases to be replicated automatically without needing to modify the config repeatedly. However, the issue with your slave server not reflecting changes, despite the binary log position changing, suggests a misconfiguration in the replication setup rather than in the logging itself. Ensure that the slave’s configuration includes the correct master coordinates and that the replication user has the necessary privileges for all databases. It’s also important to check that both servers have unique server-id values and that the slave’s relay logs are processing correctly. I faced similar issues in the past, which were typically related to permissions on newly created databases. Running SHOW SLAVE STATUS on the slave might provide insights into any errors affecting replication.

3

mysql logs everything to binlog by default, so your ignore setup should catch new dbs. sounds like a replication issue though - check if the slave’s running both IO & SQL threads with show processlist. it might connect fine but just stop processing due to disk space or network problems.

4

Yes, the default behavior captures everything when you don’t configure specific databases, so your ignore approach should work. However, the issue with log-bin-ignore-db is that it only ignores statements when the current database context matches what you’re ignoring. Cross-database queries or fully qualified table names will still get logged even for ignored databases. Your slave might not be picking up changes while the binary log position keeps advancing, indicating potential SQL thread errors. Check your MySQL error log on the slave, and look at SHOW SLAVE STATUS for any Last_SQL_Error messages. I’ve encountered this issue before, often due to character set mismatches between master and slave or stricter SQL modes on the slave.

5

Database replication gets messy when you’re constantly adding new databases. The ignore approach works, but you’ll still hit problems with permissions, config drift, and monitoring multiple slaves.

I’ve managed dozens of client databases and dealt with this exact mess. The real problem isn’t the binlog config - it’s keeping replication reliable as you scale. Manual config updates, permission management, and troubleshooting failed replications becomes a total nightmare.

I solved this by automating the whole database replication pipeline with Latenode. Instead of fighting MySQL replication configs, I built workflows that auto-detect new databases, set up replication with proper permissions, and monitor each replica’s health. New client database gets added? Latenode handles replication setup automatically.

The automation catches replication lag and permission issues before they break stuff. You can set alerts for failed replications and auto-retry with proper error handling.

This killed all the manual config work and gave me rock-solid replication across multiple client databases without babysitting.