6
1Know 道歉聲明 (docs.google.com)
qrtt1 積分 5 編輯於

看起來是設計的人也許有看手冊,但操作的人沒看手冊 xd

雷設計

1Know 系統放置在 Amazon EC2 服務上,因執行效能的考量,採用 Amazon EC2 的 Instance Store 服務作為資料儲存及備份機制,此機制順暢運行了7個月。

中招的操作

2015/3/28 凌晨進行 1Know 系統更新,檢查發現 Amazon 上的資料主機磁碟空間需擴充。在加掛磁碟空間後,卻發現該主機無法啟動,並於多次重新啟動(Reboot)失敗後,決定先將該資料主機先停止(Stop)再啟動(Start)。然而當 Amazon 執行 Stop 後,就把 Instance Store 上所有資料刪除,導致主機上的資料庫與備份資料全部被清除。
IngramChen 積分 4

TL;DR:

我犯了全天下工程師都會犯的錯

就算不曉得 Instance store 的缺限,有 daily backup 的話最慘只損失一天資料而已。

唉... 就是單純的沒備份,損失才會這麼慘重,每個工程師 (operator) 都會歷經這麼一次慘痛的教訓,才會覺悟吧。這就像... 呃,初戀破滅的那一刻。

我經歷過最慘的是 drop 整個 mysql db,全資料掉入了黑洞回不來了...

qrtt1 積分 2 編輯於

覺得 instance store 應該改回舊名 ephemeral disk,比較讓人有意識到他會消失。

db 我們遇過有人把更新的 condition 寫錯,讓所有 data 的 timestamp 都更新了,這影響到其他利用 timestamp 做差異份的機制qq

koji 積分 0

成本還是效能考量到只用 instance store ? 不管怎樣有備份的話就不會這樣了 orz。

haocheng 積分 0

我猜應該是效能考量吧?不過完全沒做備份真的太誇張了...

qrtt1 積分 3

1know1 在 FB 上的說明。果真大家換到 Google Compute Engine 主要是為了速度 xd