Coordinator stopped because there were error(s) in the worker(s).

MySQL5.7  多源复制其中的一个chaannel 报错如下：

mysql> select * from performance_schema.replication_applier_status_by_worker where  LAST_ERROR_NUMBER>0\G
*************************** 1. row ***************************
         CHANNEL_NAME: master_5
            WORKER_ID: 6
            THREAD_ID: NULL
        SERVICE_STATE: OFF
LAST_SEEN_TRANSACTION: ANONYMOUS
    LAST_ERROR_NUMBER: 1146
   LAST_ERROR_MESSAGE: Worker 6 failed executing transaction 'ANONYMOUS' at master log mysql_bin.000063, end_log_pos 799245561; Error executing row event: 'Table 'mysql_proxy.info' doesn't exist'
 LAST_ERROR_TIMESTAMP: 2017-09-22 18:27:54
1 row in set (0.00 sec)

show slave status for channe ‘master_5' \G

 Replicate_Wild_Ignore_Table: mysql.%,information_schema.%,performance_scheme.%,sys.%,percona.%
                   Last_Errno: 1146
                   Last_Error: Coordinator stopped because there were error(s) in the worker(s). 
                   The most recent failure being: Worker 6 failed executing transaction 'ANONYMOUS' at master log mysql_bin.000063, end_log_pos 799245561. See error log and/or performance_schema.
                   replication_applier_status_by_worker table for more details about this failure or others, if any.

原来SLAVE没有mysql_proxy 这个库。

mysql> SELECT SCHEMA_NAME from information_schema.SCHEMATA  where SCHEMA_NAME like 'mysql%';
+-------------+
| SCHEMA_NAME |
+-------------+
| mysql       |
+-------------+
1 row in set (0.00 sec)

Master 上是有的

mysql> SELECT SCHEMA_NAME from information_schema.SCHEMATA  where SCHEMA_NAME like 'mysql%';
+-------------+
| SCHEMA_NAME |
+-------------+
| mysql       |
| mysql_proxy |
+-------------+
2 rows in set (0.00 sec)

Slave 上为什么没有同步过来mysql_proxy 这个库呢？

原来在备份数据库的时候过滤掉了mysql相关的库，所以导致mysql_proxy库没备份。

for database in   `$mycmd  -e "show databases;"|grep -Ev "Database|information_schema|performance_schema|test|mysql|percona"`
do
${DUMP_InnoDB} ${database} |gzip >> $BACKUPPATH/$BACKUPDATE/$BACKUPPORT/$(date +%w).sql.gz

解决：

由于只是一个schema中的一个配置表，记录就几条，更新也不频繁。在master上导出后，直接在slave上恢复，跳过几个错误就ok了。

如果涉及到的schema和记录比较多，就需要重返工，新建立同步关系了。

如何避免上述问题呢：

如果能在master导出前和slave导入后对比一下schema的数量，或许会避免这个问题。

mysql> SELECT count(1) from information_schema.SCHEMATA  where SCHEMA_NAME  not in ('mysql','information_schema','performance_scheme','sys','percona');
+----------+
| count(1) |
+----------+
|       25 |
+----------+

还好是在测试中发现了这个脚本的问题，如果在线上发现这个问题，就是一个事故了。

另外，数据库起名的时候，最好起一些与业务相关的名字 ，不要使用数据库的关键字。