Bug #41747 binlog_wild_ignore_table
Submitted: 25 Dec 2008 17:45 Modified: 14 Jan 2014 17:26
Reporter: Serdar S. Kacar Email Updates:
Status: Verified Impact on me:
None 
Category:MySQL Server: Replication Severity:S4 (Feature request)
Version:5.5.13, 5.5.35, 5.6.16, 5.7.3 OS:Any
Assigned to: CPU Architecture:Any
Tags: RBL

[25 Dec 2008 17:45] Serdar S. Kacar
Description:
Especially while using ROW based logging, there is a dilemma : it tends to be huge. This is the trade-off against much needed things RBL (and RBR) provides.

While manipulating the base data , we gladly pay the price.

When we use non-temporary tables for temporary purposes like case analysis, it becomes real dilemma. Consider this ,
- John is using PHP interface where session (and temporary tables) is lost between the pages.
- The workspace consisting many datasets that he will work on compiled from various tables for once.
- The workspace is a database (schema) having unique name but standard prefix (like 'tmp4471515').

Since we do not have binlog_wild_ignore_table option, all those useless-regarding-binary-log workspace data leaks into the binary log and waste storage space until logs are purged.

A workaround that would open doors unintended results is exposing SQL_LOG_BIN by stored procedure. But this has two drawbacks :
1. There is a reason even @@SESSION.SQL_LOG_BIN requires SUPER privilege. 
2. Control is transferred to the connection. High level application may be buggy and would use wrong SQL_LOG_BIN state unintentionally.

Could you give us "binlog_wild_ignore_table" option, like "replicate_wild_ignore_table" ?

How to repeat:
N/A
[31 Dec 2008 16:36] Serdar S. Kacar
Another alternative is separating binary log and binary log for replication, which is similar to the “dummy” slave process on the master host mentioned in the blackhole engine documentation. The properties are ,

Binary Log :
- Recycled quickly
- Good for crash recovery purposes

Binary Log For Replication :
- Fat & Waste (in terms of replication) data filtered out locally
- Have longer persistence

Common :
- Does not interfere with the storage engine selections
- Easier to develop/maintain solution
[14 Jan 2014 17:26] Sveta Smirnova
Thank you for the reasonable feature request.