Fix for BUG#2983 "If statement was killed on master, slave errors despite replicate-wild-ignore-t"

We introduce a new function mysql_test_parse_for_slave().
If the slave sees that the query got a really bad error on master
(killed e.g.), then it calls this function to know if this query
can be ignored because of replicate-*-table rules (do not worry
about replicate-*-db rules: they are checked so early that they have
no bug). If the answer is yes, it skips the query and continues. If
it's no, then it stops and say "fix your slave data manually" (like it
did before this change).


mysql-test/r/rpl_error_ignored_table.result:
  result update
mysql-test/t/rpl_error_ignored_table-slave.opt:
  ignore more tables
mysql-test/t/rpl_error_ignored_table.test:
  we test if a killed query on the master, is ignored on the slave
  if the tables it involves should be excluded because of replicate-*-table
  rules.
sql/log_event.cc:
  If the query got a really bad error on the master (thread killed etc),
  parse it to test the table names: if the replicate-*-do|ignore-table
  rules say "this query must be ignored" then we exit gracefully;
  otherwise we warn about the bad error and tell DBA to check/fix it.
  Before this change, we always warned and stopped.
sql/mysql_priv.h:
  new function
sql/slave.cc:
  don't print error immediately as we need to do one more test to
  be sure.
sql/sql_parse.cc:
  we add a function mysql_test_parse_for_slave(), to be used only
  by the slave if it wants to know if the query should be ignored or not;
  so this function only parses the query, does not execute it.

1 files changed, 0 insertions, 7 deletions

diff --git a/sql/slave.cc b/sql/slave.cc
index 30052e874b3..d6dda473be0 100644
--- a/sql/slave.cc
+++ b/sql/slave.cc
@@ -2250,13 +2250,6 @@ int check_expected_error(THD* thd, RELAY_LOG_INFO* rli, int expected_error)
   case ER_NET_ERROR_ON_WRITE:  
   case ER_SERVER_SHUTDOWN:  
   case ER_NEW_ABORTING_CONNECTION:
-    slave_print_error(rli,expected_error, 
-                      "query '%s' partially completed on the master \
-and was aborted. There is a chance that your master is inconsistent at this \
-point. If you are sure that your master is ok, run this query manually on the\
- slave and then restart the slave with SET GLOBAL SQL_SLAVE_SKIP_COUNTER=1;\
- SLAVE START; .", thd->query);
-    thd->query_error= 1;
     return 1;
   default:
     return 0;