目前我們在使用 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 查看方法