2017/08/15 11:44:10
y_uuki
先日の障害の技術的詳細について公開しました。
2017/08/15 11:46:58
lesamoureuses
ほー “PostgreSQL 9.3のデフォルト設定では、マスターのタイムラインIDがインクリメントされても、スレーブが新しいタイムラインIDをもつWALを受け付けずにレプリケーションが停止する仕様になっています”
2017/08/15 11:55:34
tmd45
すごい詳細
2017/08/15 12:00:49
master-0717
障害の原因報告 兼 知見の共有
2017/08/15 12:04:47
netcraft3
recovery_target_timeline = 'latest'忘れか。自分もフェイルオーバーでマスター昇格したDBサーバーと今までのマスターとの整合性が取れなくなったことある。
2017/08/15 12:16:26
W53SA
なるほどなぁ
2017/08/15 12:22:21
halfrack
時系列DB ではなくメタデータDB の障害
2017/08/15 12:31:53
wata88
移行時にファイルオーバーを無効にして作業するとよかったのでは？という気がしたけど、postgresql詳しくないのでわからない
2017/08/15 13:33:09
yoshis1210
再発防止策としては、今回の原因となった設定項目についての対処だけではなく、テストと本番の設定／環境／手順の差異について精査する仕組みも考えた方がいいと思うけど。
2017/08/15 13:38:21
digitalglm
[mackerelio:]
2017/08/15 14:20:38
knjname
“recovery.confファイルに、recovery_target_timeline = 'latest'を設定した状態でレプリケーションしている場合、スレーブは新しいタイムラインIDを受け付け、引き続きレプリケーションを継続します。”
2017/08/15 14:24:12
katzchang
リハーサル時と設定値が異なっていたっていうあたりがポイントですかね
2017/08/15 14:35:38
karupanerura
知見
2017/08/15 14:42:22
ANNotunzdY
recovery_target_timeline
2017/08/15 14:47:01
hiby
とてもいい資料だ
2017/08/15 15:05:41
showii
該当データベースサーバとのネットワーク疎通がとれなくなり、の原因は結局不明ということですね。
2017/08/15 15:16:41
mana-cat
再発防止策まで詳細に書かれている
2017/08/15 15:39:18
oooooo4150
細かい
2017/08/15 16:24:25
yogasa
Mackerel なんて重要な業務データが載ってるわけでもないんだから，そんな目くじら立てんでもいいと思うが……
2017/08/15 16:55:55
hiroomi
ワクワクはしたんだろうけど、直感的にサーバー監視はできなかったのか。
2017/08/15 16:56:26
honeybe
詳細報告きた / mackerelチームの皆様お疲れ様でした。
2017/08/15 17:00:59
kuniku
テストにおいて設定を限りなくproductionに近づける　ことと、差異がある場合の妥当性をレビューする必要がありそう。
2017/08/15 17:51:19
SigmaG2
詳細に纏められており、非常に好感が持てます
2017/08/15 18:07:43
makinoshi
直接の原因は不明とのこと。他山の石として心に止めとこう。
2017/08/15 19:00:49
hase_done
“移行テストの際には、孫スレーブにて、recovery_target_timeline = 'latest'を正しく設定していたため、移行テスト時にはレプリケーション停止が発生しませんでした。”環境の差を解消するか把握しておかないとまた起きそうな
2017/08/15 19:05:14
lovevoiceryu
「意図しない」「意図せぬ」「意図せず」って、トラブルってそういうもんだよ。意図せぬ事態が発生してもデータを復旧できるようにしておくのが移行計画だ。
2017/08/15 19:26:49
xact7
怖い
2017/08/15 19:39:59
ya--mada
DBマイグレーションな。監視データでもpostgres使っている部分があるんだ。
2017/08/15 19:45:00
lli
胃が痛くなるな
2017/08/15 20:09:07
nippondanji
心中お察し案件。トランザクションによって守られた世界の外側でデータがぶっ壊れると、復旧は絶望的だよね。
2017/08/15 20:14:58
catatsuy
資料としておもしろいエントリーありがとうございます。おつかれさまでした。
2017/08/15 20:16:57
MINOMUCCCHI
こういうの見てると胃が痛くなる
2017/08/15 20:36:05
baronhorse
この手のサービスでこれは致命的な感じする
2017/08/15 20:41:49
gui1
どんまい(´・ω・｀)
2017/08/15 20:44:17
beerbeerkun
“移行作業後のアプリケーションの動作確認中に、特定時間帯のデータを消失していることを発見し、データの復旧を試みました。” キツい時間帯だよね。しかしmackerelってメトリクスもRDBなのかね。マスター系だけか。
2017/08/15 20:56:28
nakunaru
しんどいわー
2017/08/15 21:42:14
rryu
こういうのは手順書に書いてあることだけを実施するリハーサルみたいなことをしないとなんらかミスるよね……
2017/08/15 21:43:26
mukimi
原因のお粗末さに反して、お疲れ様的な賞賛コメントが多いところが詳細報告すればなんでも許される感があって気持ち悪い
2017/08/15 21:56:33
progrhyme
詳しい
2017/08/15 22:38:37
uva
世界で一番failoverの経験値が溜まっているRDSに任せた方が、人間が組む冗長構成より信頼できるのですよね
2017/08/16 00:05:52
yuno001
もう一段深い再発防止をした方が良いと思うなー。
2017/08/16 00:36:57
awkad
データ消失させてこれで許されるんだからお気楽だ。そんなシステムをやってるスタートアップが銀行など消えたらとんでもないことになるシステムを作ってる人たちを馬鹿にしてるんだからどうかと思う。
2017/08/16 02:15:34
ore_de_work
無償だしディスク残量ワーニングと生存確認がメールでとんでくればいいよ。お金払ってる人はざんねんでした。
2017/08/16 02:41:29
camellow
まったくお粗末だし「意図せぬ」の連呼に嫌気がさすけど失敗事例とその原因・対策の情報は誰かの参考になるから他人事としてみればまあいいんじゃないスか？って感じ。
2017/08/16 06:22:31
twotiger
お粗末！典型的な意識高い系って感じする
2017/08/16 07:51:49
bkios
お疲れ様でしたコメントは馴れ合いが気持ち悪いが、嬉々として叩いてる奴らも気持ち悪い。親でも殺されたんだろうかw／関係ないけど、自撮りアイコン野郎の自撮りアイコン気持ち悪すぎわろた
2017/08/16 08:35:04
kabukawa
意図していないものを考えて対応するのが当たり前って言われても、それに気付いていたら対応はするわけで、なんか色々お疲れ様でしたという言葉しか出ない。データは消えないようにしたいけどね。。。
2017/08/16 08:48:53
houyhnhm
主因のネットワーク障害への対策、そこから派生した障害への対策、というような形で対策をちゃんと清書した方がいいよ。
2017/08/16 09:03:01
tmatsuu
CPU負荷の内訳(usr,sysなど)が気になるな。基盤よりは何らかのioボトルネックがくさそう。あと孫までレプリケーションされてなかったことから再発防止策としてレプリケーション遅延監視も追加したい。
2017/08/16 09:08:11
yutam7
ポスグレってフェイルオーバー無効に出来ないの？
2017/08/16 09:12:16
side_tana
なるほどなるほど レプリカ遅延してたのかな、しかし1時間となると何かしらアラート上がりそうだけど，メンテ中だから切ってたのかな，とか思ってたが メンテ中ってこういうミス気づきにくい環境になってしまうよな
2017/08/16 10:37:27
koyancya
staging 環境でやってうまくいった移行テストの手順を自動でリプレイしてくれるような仕組みがないと、もし、わしがオペレーションしたら多分なにか他のミスをして死にそう......
2017/08/16 10:47:23
h_taiji
この障害報告だと、db0001とdb0002のテーブル間差分をとって、db0002にインサートすれば、データ復旧できそうだけど、、、時系列でデータ持ってて過去データを更新されないテーブルであれば
2017/08/16 10:48:10
roromoyo
SLAに基いて今回のインシデントはどのように捉えているのでしょうか？
2017/08/16 11:47:19
murasaki11
手順書とリハーサル大事
2017/08/16 12:06:09
bell_chime_ring238
喧嘩したい訳じゃないが、真に必要なデータとそうでないデータの存在意義を考えずにはいられない。ファーストサーバの事例も久々に再読。こういうサービス提供者は事例集積に努めて適切なSLA設定を意識してほしい
2017/08/16 17:59:04
Nyoho
そーだいがジョインしたのにPostgreSQLのPITRうまいことできんかったなんて信じられん……
2017/08/16 19:18:11
rjge
“移行テストの際には、孫スレーブにて、recovery_target_timeline = 'latest'を正しく設定していたため” 単純に本番で手順すっ飛ばしてしまったってことなんだろか。想像しただけで胃が痛くなるヒューマンエラーだ。
2017/08/17 09:25:50
wnoguchi0727
あーきもいきもいこんぐらいのことで目くじら立てるやつがいるからどんどん窮屈な世の中になってくんだよ。
2017/08/17 12:51:06
smallpalace
オンプレから移行かあ。拡張しやすさとリードタイムとか気にしてたんかな。移行中のデータ更新がなければマシだったのかな。
2017/08/18 15:41:44
jin255
うーむ・・・。