成人免费xxxxx在线视频软件_久久精品久久久_亚洲国产精品久久久_天天色天天色_亚洲人成一区_欧美一级欧美三级在线观看

使用過MySOL的Binlog嗎?看看如何用Binlog排查阿里開源項目Otter的問題

數據庫 MySQL
MySQL的binlog相信大家都有所耳聞,但是可能沒有真正日常使用過。因此,本文結合一個otter小坑的排查案例,來分享下binlog的日常使用方式。

 MySQL的binlog相信大家都有所耳聞,但是可能沒有真正日常使用過。

因此,本文結合一個otter小坑的排查案例,來分享下binlog的日常使用方式。

重點了解下:

  • binlog的導出方式
  • binlog的解析方式
  • 結合案例分享下開源項目otter的一個小坑

1.案例背景

某個周末突然收到報警,發現線上多云數據庫的數據同步任務掛起,顯示日志寫入數據失敗。


錯誤原因非常明顯:

唯一索引沖突。

查看了一下源庫的數據內容,確實已經update完畢。而目標庫的數據內容,確實存在沖突導致無法update。

2.排查過程

這個數據同步任務,使用了阿里開源的數據庫同步項目otter。難道遇到了什么bug?

otter項目是阿里巴巴開源的數據庫同步系統。

基于數據庫增量日志解析,準實時同步到本機房或異地機房的mysql/oracle數據庫的一個分布式數據庫同步系統。

直接開始排查問題。

2.1 表結構是否一致

為什么源庫沒有沖突,目標庫會有沖突呢?是不是表結構不一致?或者是源庫發生了表結構變更沒有同步到目標庫?

確認了下源庫的表結構和目標庫表結構是一致的,且都有對應的唯一索引udx_position。

2.2 排查源庫binlog

那源庫到底是怎么更新成功的?只能撈一下binlog了。

首先導出線上正在使用的binlog文件。

在數據庫上執行

  1. flush logs 

這個命令會關閉當前正在寫入的binlog文件,然后生成一個序號加1的新的binlog文件讓mysql server繼續使用。

等待幾分鐘,讓當前的binlog落盤為日志文件,本案例中為xxxx_binlog_mysqlbin.000005。

然后下載到本地。

通過mysqlbinlog命令解析,輸出為指定文件xxx.binlog,如下:

  1. mysqlbinlog  --start-datetime='2020-11-20 18:17:00' --stop-datetime='2020-11-20 18:21:01' --base64-output=decode-rows -v -d db xxxx_binlog_mysqlbin.000005 > xxx.binlog 
  • binlog格式binlog_format采用row模式。僅保存記錄被修改細節,不記錄sql語句上下文相關信息優點:能非常清晰的記錄下每行數據的修改細節,不需要記錄上下文相關信息,因此不會發生某些特定情況下的procedure、function、及trigger的調用觸發無法被正確復制的問題,任何情況都可以被復制,且能加快從庫重放日志的效率,保證從庫數據的一致性。
  • 通過 --start-datatime和--stop-datetime指定解析的起止時間
  • row模式生成的sql編碼需要解碼,不能用常規的辦法去生成,需要加上相應的參數(--base64-output=decode-rows -v)才能顯示出sql語句

binlog的內容解析后sql的過程如下(為了更好地看清過程,這里不展示binlog原文,而是一個邏輯過程):


我們能清楚地看到,源庫通過一個事務中,交換position(唯一索引的列)的值,達到更新唯一索引而不造成沖突的目的。

那目標庫為什么會沖突呢?

2.3 查看目標庫的sql審計

由于數據同步失敗掛起,所以目標庫的同步數據暫時不會寫入對應的binlog記錄。

因此,我們需要通過sql審計來查看目標庫的寫入情況。

這里同樣展示sql審計中撈出的相關過程:


Oh~ My~ God!

事務中間的update交換過程居然被合并了!!

所以造成了唯一索引沖突,更新失敗。

3.求證

重新去翻了一遍otter的wiki,看到了關于《otter數據入庫算法》說明。

https://github.com/alibaba/otter/wiki/Otter%E6%95%B0%E6%8D%AE%E5%85%A5%E5%BA%93%E7%AE%97%E6%B3%95


確實存在操作合并的情況。

這樣做許多好處:

  • insert/行記錄update 執行merge sql,解決重復數據執行
  • 合并算法執行后,單pk主鍵只有一條記錄,減少并行load算法的復雜性(比如batch合并,并行/串行等處理)
  • 同步速度相比于mysql的復制,拋棄了強一致性,約有5倍左右的性能提升

找了下源碼,定位到DbLoadAction類


令人遺憾的是,我們發現竟然沒有開關可以控制。

4.解決方案。

到上面基本已經水落石出,找到了問題的根本原因。由于otter對事務內的update操作進行了合并,導致了目標庫唯一索引沖突。

那怎么解決呢?

看到文檔上有這么一句話


那么,對應到這個案例,或者說其他唯一索引的變更,只能通過 先刪除,再插入,而不是通過update進行交換。

 

 

責任編輯:姜華 來源: 阿丸筆記
相關推薦

2019-05-07 09:31:41

TiDBMySQL數據

2021-07-12 08:06:32

Java

2023-01-04 08:14:48

binlog參數生效

2020-04-23 10:07:45

工具IDEA阿里巴巴

2021-06-30 13:57:07

Arthas JVMTI

2025-01-22 16:00:00

MySQL數據庫Binlog

2010-05-18 12:24:16

MySQL binlo

2017-09-13 18:30:38

數據庫數據異構BINLOG+MQ

2024-03-14 14:18:58

MySQL業務設計事務

2020-03-23 10:06:05

工具代碼開發

2019-11-01 09:23:31

開源項目UI

2023-06-08 07:37:35

MySQLbinlog機制

2018-05-14 13:51:39

RDS Binlog架構Kafka集群

2021-06-28 08:00:00

Python開發編程語言

2023-04-11 08:26:34

2022-03-15 11:31:17

MySQL日志格式

2019-08-16 14:18:38

CPU故障

2025-05-06 00:43:00

MySQL日志文件MIXED 3

2022-09-23 13:24:21

MySQL數據庫

2019-02-26 09:42:14

開源技術 趨勢
點贊
收藏

51CTO技術棧公眾號

主站蜘蛛池模板: 亚洲欧洲成人av每日更新 | 蜜桃视频成人 | 久久另类视频 | 国产精品久久精品 | 五月激情综合 | 久久久久久免费毛片精品 | 一呦二呦三呦国产精品 | 中文字幕一区在线观看视频 | 狠狠做深爱婷婷综合一区 | 成人免费观看男女羞羞视频 | 久久免费观看一级毛片 | 国产探花在线观看视频 | 国产91精品久久久久久久网曝门 | 成人午夜性成交 | 国产一区二区三区 | 一区二区三区视频在线 | 午夜精品久久久久久久久久久久久 | 在线观看视频一区 | 日韩精品亚洲专区在线观看 | 国内久久精品 | 国产精品一区二区在线 | 国产成人99久久亚洲综合精品 | 在线观看中文字幕av | 久久一热 | 国产成人99久久亚洲综合精品 | 日韩在线一区二区三区 | 99久久精品免费看国产小宝寻花 | 美女黄网站 | 91毛片网| 五月激情六月婷婷 | 精品久久99 | 9191在线播放| av网站在线播放 | 精品一区二区三区在线观看 | 中文字幕乱码亚洲精品一区 | 国产精品污www一区二区三区 | 国产成人午夜精品影院游乐网 | 国产一区不卡 | 欧美偷偷 | 一级黄色毛片a | 久久er精品 |