阿里RDS一次資料異常的定位過程

2021-06-21 16:30:17 字數 303 閱讀 2317

系統有部分資料放在阿里的rds上,今天發現某些資料查詢不出來

先檢查rds的日誌,可以看到當時的insert語句,但是select就查不到,所以一開始懷疑是rds的資料丟失。後來用mysqlbinlog命令檢查binlog檔案,才發現真正的原因

原來是insert的字段有33位,而該字段的型別是varchar(32)。但是rds截去了最後一位,然後寫入資料庫。所以用33位的條件去select,就查不到

關鍵是rds的sql審計,記錄的是鏈路上的語句,這時候還是33位的,所以看不出異常來;而binlog記錄的,才是真正寫入的資料,這時候是32位的

阿里RDS一次資料異常的定位過程

系統有部分資料放在阿里的rds上,今天發現某些資料查詢不出來 先檢查rds的日誌,可以看到當時的insert語句,但是select就查不到,所以一開始懷疑是rds的資料丟失。後來用mysqlbinlog命令檢查binlog檔案,才發現真正的原因 原來是insert的字段有33位,而該字段的型別是va...

Redis一次資料丟失

一台redis伺服器,4核,16g記憶體且沒有任何硬體上的問題。持續高壓執行了大約3個月,儲存了大約14g的資料,設定了比較完備的s e引數。而就是這台主機,在一次重起之後,丟失了大量的資料,14g的資料最終只恢復了幾百兆而已。正常情況下,像redis這樣定期回寫磁碟的記憶體資料庫,丟失幾個資料也是...

記錄一次kernel記憶體洩漏的查詢定位過程

bug定位過程 char wr pr debug begin u8 const data,u32 len,char string char wr pr debug end char string void test 一眼可能不容易看出上面的有什麼問題,有kmalloc,有kfree啊,好像成對出現的...