GitLabのみなさん、PostgreSQL 9.6とレプリケーション機能、バックアップの仕組みを使ってくれてありがとう。
今回、GitLabのデータベースが消えてしまったのは残念です。
https://about.gitlab.com/2017/02/01/gitlab-dot-com-database-incident/
振り返りの分析に対するコメントができるように、こういった情報を公開してくれてどうもありがとう。
レプリケーションの遅延を監視していたのはいいことですし、私としてはとてもうれしいです。4GBのレプリケーション遅延は問題ないこともありますし、大きな注意を払うべきところではないでしょう。私は最近、特定状況下で1分未満のレプリケーションの停止が起きてしまうというバグを修正しました。それに対する修正はリリース済みで、PostgreSQL 9.6の次のメンテナンスリリースに含まれる予定です。そのバグを踏んだのかどうかは定かではありませんが、そうだとしたら、(上の記事に書かれているような)スローダウンを起こすには十分です。あなたたちのやり方の開放性は、つまり私たちもそうするべきだということなので、このバグについてここで触れました。
レプリケーションを再起動する必要はおそらくなかったでしょうが、もしスタンバイノードをちゃんと停止していたら、レプリケーションはきれいに切れているはずです。そしてレプリケーションがきれいに切れていれば、使用中だったWALSenderが解放されていると思ってよいでしょうし、それから接続したら、WALSenderの接続が使用可能になっているでしょう。普通の使い方では、max_wal_sendersパラメーターを変更する必要はないはずです。したがって、スタンバイノードが乱暴にシャットダウンされたためにレプリケーション接続がきれいに切断できなかったようです。
きれいにシャットダウンできなかったことはWALSenderの接続が十分な速さで解放されなかったということで、新しい接続はさらに接続を増やそうとし、そのためmax_wal_sendersの上限に達して値を増やす必要があったわけです。もともとmax_wal_sendersがいくつだったのかは分かりませんが、32といった大きな値である必要はなかったはずです。普通は2から4で間違いないでしょう。max_connections = 8000は非常に大きな値なので、いずれにしても2000まで減らすのが理に適っています。
pg_basebackupは、バックアップのために最新のデータを取れるようにするためにまずチェックポイントを発行します。このチェックポイントは、ディスクに高負荷をかけないように負荷が調整されています。そのため、これには数分かかり、起動時のデフォルトでは4分程かかるのが一般的です。その間、マスターでのチェックポイントを待っているのでpg_basebackupのプロセスは静かにしています。
この一連の流れの中には、私から見て新しいPostgreSQLのバグやソフトウェアの使い方の問題はありません。いくつかの問題に遭遇してはいますが、正しく動作するようにするための一般的に使えるツールが存在しています。
データディレクトリーを手動で削除するのが危険なのはお分かりの通りです。レプリケーションをスクリプトで管理するのは一般的なので、レプリケーションがスタンバイではなくマスターで設定されていることをチェックするテストがスクリプトに組み込まれていれば、エラーを検知できたでしょう。私たちは、repmgrのようなツールをこの目的に使うのをおすすめします。repmgr 3.3が2017年1月6日にリリースされており、定期的にメンテナンスされています。
バックアップからのリカバリーは間違いなく重要です。だからこそ我々はバックアップの管理のためのbarmanというツールを提供しています。barmanは、S3との組み合わせで動き、まずいことが起きた時に必ず動くように完全にテストされています。barman 2.1は2017年1月5日にリリースされて、こちらも定期的にメンテナンスされています。
私は何年にも渡って、リカバリーの練習をすることでバックアップが正しいかテストすべきだということを言い続けてきていますし、その講義やカンファレンスでの発表もしています。repmgrをレプリケーション管理に、barmanをバックアップ管理に、それぞれ使うことをおすすめします。
何か不満を感じているようでしたら申し訳ないですが、私たちはPostgreSQLを改善するための提案はいつも受け付けています。
2ndQuadrantはPostgreSQLのコアバックアップ技術の筆頭作者ですし、バージョン8.0の頃からバックアップとレプリケーション技術を拡張し続けています。2ndQuadrantは、緊急の問題の際にPostgreSQLの24/7サポートを提供していますし、世界中でトレーニングも提供しています。
2ndQuadrant社CTO兼PostgreSQLコミッター Simon Riggs
