目前我们在使用 Maxwell 在读线上机器的 binlog 同步我们的离线数据库。
这次错误定位上，首先线要确定问题是发生在生产者 还是队列 还是消费者。经过查看各机器上任务的运行日志，定位到了问题出在了任务的生产者上。
于是我试图去调看生产者上的 Maxwell 日志。之前一直跑得好好的 Maxwell 错误日志里面打出了这样一段内容：
17:53:24,420 INFO OpenReplicator - starting replication at mysql-bin.000055:17870889 17:53:24,944 INFO TaskManager - stopping 3 tasks 17:53:24,944 ERROR TaskManager - cause: com.zendesk.maxwell.schema.ddl.InvalidSchemaError: Couldn't find database 'remain_db' at com.zendesk.maxwell.schema.Schema.findDatabaseOrThrow(Schema.java:52) ~[maxwell-1.10.3.jar:1.10.3] at com.zendesk.maxwell.schema.ddl.TableCreate.resolve(TableCreate.java:34) ~[maxwell-1.10.3.jar:1.10.3] at com.zendesk.maxwell.schema.ddl.TableCreate.resolve(TableCreate.java:13) ~[maxwell-1.10.3.jar:1.10.3]
可以看到 Maxwell 尝试去读 MySQL binlog.00055:17870889 这条 position 的内容是需要 find 一个叫 remain_db 的东西，由于没有 remain_db 所以这个行为失败了，导致整个同步的生产者卡住了。
排查这个问题我们需要知道一件事情，就是 Maxwell 会主动在被同步的数据库上面建立一个自己的数据库叫 Maxwell like this:
Maxwell 数据库里面会记录各种自己同步的时候会需要用到的信息，当他在同步到主数据库有建库建表相关 dll 的时候，他会使用相关语句在 自己的数据库把这些东西建出来。这里提示的找不到 remain_db 就是因为 Maxwell 自己数据库维护的 databases 表里面没有 remain_db 这个数据库的记录，所以就报错了。
正常维护的时候为啥会有漏掉的 DDL ？ 仔细想想如果 binlog 没有出过问题是不应该发生这种情况的。所以如果着么思考的话应该很容易的定位到问题出在了 binlog 日志上面。后来我通过的 MySQL 的配置文件的查看配置的时候发现了问题所在，原来是我们数据库指定只同步了某一个数据库，但是之前有人在数据库 use 某个库的时候还执行了别的库的创建操作，导致这个创建行为的 DDL 被错误的同步到了 user 表的 binlog 上，也导致了这次错误。
发现了错误解决起来就相对容易了，由于错误信息以及 Maxwell 的数据表中都明确记录了 binlog 的中断位置，我只需要前往中断位置跳过相关语句就可以了。
具体的 binlog 查看操作命令可以参考 reference 里面的内容 这里只提几个最实用的，例如我会实用
mysqlbinlog --start-position=205 --stop-position=314 mysql-bin.000001 来指定开始结束位置获取中间的 binlog 信息 我也可以使用 mysqlbinlog mysql-bin.0000001 | grep 'xxxx' 来获取我关注的信息
另外还可以在 mysql shell 里面使用类似语句：
show binlog events from 4 limit 2;
来查看指定 position 位置的以及指定多少条数来查看相关的 binlog 日志。
Reference:
http://soft.dog/2016/06/13/dig-mysql-binlog/#%E5%91%BD%E4%BB%A4%E6%B1%87%E6%80%BB MySQL binlog 查看方法