Skip to content
  • Marc Alff's avatar
    658a635b
    Bug#14741537 - MYSQL 5.6, GTID AND PERFORMANCE_SCHEMA · 658a635b
    Marc Alff authored
    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().
    658a635b
    Bug#14741537 - MYSQL 5.6, GTID AND PERFORMANCE_SCHEMA
    Marc Alff authored
    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().
Loading