過去数年間、PostgreSQLの採用が増えています。 PostgreSQLは素晴らしいリレーショナルデータベースです。機能的には、最高ではないにしても、最高のものがあります。 PL / PG SQL、スマートデフォルト、レプリケーション（実際にはそのままで機能します）、アクティブで活気のあるオープンソースコミュニティなど、私が気に入っている点はたくさんあります。ただし、機能だけでなく、データベースには考慮しなければならない重要な側面があります。 24時間年中無休で大規模な運用を構築することを計画している場合、データベースが本番環境に移行した後、データベースを簡単に運用できることが非常に重要な要素になります。この点では、PostgreSQLはあまりうまく持ちこたえません。このブログ投稿では、PostgreSQLでのこれらの運用上の課題のいくつかについて詳しく説明します。ここでは基本的に修正できないものはなく、優先順位付けの問題だけです。うまくいけば、これらの機能に優先順位を付けるために、オープンソースコミュニティに十分な関心を集めることができます。
1。マスターフェイルオーバーの自動クライアントドライバー検出なし
PostgreSQLクライアントドライバーは、マスターフェイルオーバーが発生した（そして新しいマスターが選出された）ことを自動的に検出しません。これを回避するには、管理者はサーバー側にプロキシレイヤーをデプロイする必要があります。一般的な選択肢は、DNSマッピング、仮想IPマッピング、PgPool、およびHAProxyです。これらのオプションはすべてうまく機能するようにすることができますが、かなりの追加の学習と管理者の努力が必要です。データパスにプロキシが導入されている場合、パフォーマンスにもかなりの影響があります。これは、多くの新しいNoSQLデータベースに組み込まれている標準機能であり、PostgreSQLは、運用に関しては、本から抜け出すのに最適です。
2。マスターとスタンバイの間に組み込みの自動フェイルオーバーはありません
PostgreSQLマスターに障害が発生した場合、スタンバイサーバーの1つをマスターとして選択する必要があります。このメカニズムはPostgreSQLに組み込まれていません。通常、このシナリオの処理には、Patroni、Pacemakerなどのサードパーティソフトウェアツールが使用されます。これをサーバーに組み込んでみませんか？これらのサードパーティツールは一見シンプルに見えますが、これを正しく行うには、管理者側でかなりの労力、知識、およびテストが必要です。これをデータベースに組み込むことで、データベース管理者に多大な恩恵をもたらすことになります。
本番環境の管理を容易にする#PostgreSQLデータベースクリックしてツイート3。ゼロダウンタイムのメジャーアップグレードなし
PostgreSQLデータベースをダウンタイムなしでメジャーバージョンから別のメジャーバージョンにアップグレードすることはできません。基本的に、すべてのサーバーをシャットダウンし、pg_upgradeを使用してデータを新しいバージョンにアップグレードする必要があります。データコピーが含まれていないため、ダウンタイムは大きくありませんが、それでもダウンタイムはあります。 24時間年中無休のオペレーションを実行している場合、これはオプションではない可能性があります。
論理レプリケーションのリリースに伴い、オンラインアップグレードの代替オプションがあります。
- 新しいバージョンで新しいPostgreSQLマスター-スタンバイセットアップを構築します。
- 古いバージョンから新しいバージョンにレプリケートするように論理レプリケーションを設定します。
- 準備ができたら、接続文字列を変更して、古い設定から新しい設定を指すようにします。
繰り返しますが、これを機能させることはできますが、オーバーヘッドは膨大です。理想的には、ここで必要なのは、マスタースタンバイセットアップをローリング方式でインプレースでアップグレードする方法です。 MySQLアップグレードを使用すると、スレーブをインプレースで新しいバージョンにアップグレードしてから、フェイルオーバーをトリガーできます。
4。インプレースバキュームフルなし
Autovacuum / VACUUMは非常に便利で、この問題にある程度対処するのに役立ちます。テーブルの膨張を定期的に調べて、自動真空設定が適切であり、テーブルに対して適切に機能していることを確認する必要があります。ただし、autovacuumは完全には機能しません。実際には、ページをマージして削除することにはなりません。多数の更新、ワークロードの挿入と削除がある場合、ページは断片化され、パフォーマンスに影響を及ぼします。これを回避する唯一の方法は、VACUUM FULLを実行することです。これにより、基本的にすべてのページが再構築され、断片化が排除されます。ただし、このプロセスはダウンタイムでのみ実行できます。VACUUMFULLの間、テーブルはダウンします。大規模なデータセットの場合、これには数時間かかる可能性があり、24時間年中無休の操作を実行する場合の実用的な代替手段ではありません。
注：コミュニティは、この制限を克服するzheapストレージエンジンの作業をすでに開始しています。
他に役立つと思われる改善点がある場合は、コメントを残してください。
