revno: 4559
committer: Marc Alff <marc.alff@oracle.com>
branch nick: mysql-5.6-bug14741537-v4
timestamp: Thu 2012-11-08 22:40:31 +0100
message:
  Bug#14741537 - MYSQL 5.6, GTID AND PERFORMANCE_SCHEMA
  
  Before this fix, statements using performance_schema tables:
  - were marked as unsafe for replication,
  - did cause warnings during execution,
  - were written to the binlog, either in STATEMENT or ROW format.
  
  When using replication with the new GTID feature,
  unsafe warnings are elevated to errors,
  which prevents to use both the performance_schema and GTID together.
  
  The root cause of the problem is not related to raising warnings/errors
  in some special cases, but deeper: statements involving the performance
  schema should not even be written to the binary log in the first place,
  because the content of the performance schema tables is 'local' to a server
  instance, and may differ greatly between nodes in a replication
  topology.
  
  In particular, the DBA should be able to configure (INSERT, UPDATE, DELETE)
  or flush (TRUNCATE) performance schema tables on one node,
  without affecting other nodes.
  
  This fix introduces the concept of a 'non-replicated' or 'local' table,
  and adjusts the replication logic to ignore tables that are not replicated
  when deciding if or how to log a statement to the binlog.
  
  Note that while this issue was detected using the performance_schema,
  other tables are also affected by the same problem.
  
  This fix define as 'local' the following tables, which are then never
  replicated:
  - performance_schema.*
  - mysql.general_log
  - mysql.slow_log
  - mysql.slave_relay_log_info
  - mysql.slave_master_info
  - mysql.slave_worker_info
  
  Existing behavior for information_schema.* is unchanged by this fix,
  to limit the scope of changes.
  
  Coding wise, this fix implements the following changes:
  
  1)
  
  Performance schema tables are not using any replication flags,
  since performance schema tables are not replicated.
  
  2)
  
  In open_table_from_share(),
  tables with no replication capabilities (performance_schema.*),
  tables with TABLE_CATEGORY_LOG (logs)
  and tables with TABLE_CATEGORY_RPL_INFO (replication)
  are marked as non replicated, with TABLE::no_replicate
  
  3)
  
  A new THD member, THD::m_binlog_filter_state,
  indicate if the current statement is written to the binlog
  (normal cases for most statements), or is to be discarded
  (because the statements affects non replicated tables).
  
  4)
  
  In THD::decide_logging_format(), the replication logic
  is changed to take into account non replicated tables.
  
  Statements that affect only non replicated tables are
  executed normally (no warning or errors), but not written
  to the binlog.
  
  Statements that affect (i.e., write to) a replicated table
  while also using (i.e., reading from or writing to) a non replicated table
  are executed normally in MIXED and ROW binlog format,
  and cause a new error in STATEMENT binlog format.
  
  THD::decide_logging_format() uses THD::m_binlog_filter_state
  to indicate if a statement is to be ignored, when writing to
  the binlog.
  
  5)
  
  In THD::binlog_query(), statements marked as ignored
  are not written to the binary log.
  
  6)
  
  For row based replication, the existing test for 'table->no_replicate',
  has been moved from binlog_log_row() to check_table_binlog_row_based().