canal 是阿里巴巴mysql資料庫binlog的增量訂閱&消費元件, 你可以從這兒了解它.
canal 的常見使用場景之一就是資料同步, 例如我們使用 canal 就是為了把 mysql 的資料同步到 elasticsearch 中. 使用 canal 做資料同步的時候無疑會涉及到三個部分: 資料來源(mysql), canal server(接收 mysql binlog), canal client(接收 canal server 傳送的解析過的 binlog 訊息).
為了保證資料同步高可用, canal 針對上述三個部分設計了對應的高可用方案.
canal server 和 client 高可用
canal server 和 client 端的高可用方案依賴 zookeeper, 啟動 canal server 和 client 的時候都會 zookeeper 讀取資訊. canal 在 zookeeper 儲存的資料結構如下:
/otter
└── canal
└── destinations
└── flight_segment # canal 例項名稱
├── 1001 # canal client 資訊
│ ├── cursor # 當前消費的 mysql binlog 位點
│ ├── filter # binlog 過濾條件
│ └── running # 當前正在執行的 canal client 伺服器
├── cluster # canal server 列表
│ └── 10.93.61.86:11111
└── running # 當前正在執行的 canal server 伺服器
canal server 和 client 啟動的時候都會去搶占 zk 對應的 running 節點, 保證只有乙個 server 和 client 在執行, 而 server 和 client 的高可用切換也是基於監聽 running 節點進行的.
mysql 多資料來源高可用
canal 乙個例項可以配置兩個資料來源, master 和 standby. 假如 master 資料來源宕機了, canal 的 mysqldetectingtimetask 就會呼叫 heartbeathacontroller 觸發乙個在 master 和 standby 資料來源之間的自動切換.
mysqldetectingtimetask 其實就是在 canal server 和 mysql 之間維護心跳資訊, 當 mysql 掛了之後觸發一次自動切換.
當然, 為了做到上述三種高可用 canal 做了很多任務作, 在這兒就不展開講了, 以後有機會的話會仔細分析一下.
mysql的擴充套件與高可用
當應用規模越來越大時，資料往往是應用的瓶頸。如何正確的架構來擴充套件mysql成了系統好壞的關鍵。傳統的解決方法有以下幾種 幾種典型的分片規則包括 按照使用者 id 求模，將資料分散到不同的資料庫，具有相同資料使用者的資料都被分散到乙個庫中 按照日期，將不同月甚至日的資料分散到不同的庫中 按照某個特...
高併發與高可用
事發事中 事後高併發 增加處理人手 事前 副本 隔離 配額 提前預案 探知 事發 監控 報警 事中 降級 回滾 應急預案，fail 系列 事後 覆盤 思考 技改 fail 系列 當出現下游呼叫失敗時，我們一般有幾種處理方式 failretry，即失敗重試，需要配合退避時間，否則馬上重試不一定會有效果...
mysql高可用與redis快取簡記
看到有人討論redis與mysql一致性的問題，思考一下。單主一從或多從，相對單節點來說，優點 缺點也很明顯 要做到秒級容災切換，雙主是個很好的選擇，也可以附加多從，做到讀寫分離。但雙主無法迴避的乙個問題是資料的一致性，也就引出了雙主的不同用法。1.3.1 雙主單寫 其中乙個主節點只做高可用容災備份...