DBA が PostgreSQL の新たな問題を発見

いつものように、新しいクラスターをアップグレードまたは初期化するユーザーは、パフォーマンスが向上します (例: 並列インデックス スキャンの向上、マージ ジョインと関連のないサブクエリ、より高速な集計、リモート サーバーのジョインと集計に関するインテリジェンスの向上)。これらはすべて、しかし、この記事では、そのままでは機能せず、実際にその恩恵を受けるにはいくつかの手順を踏む必要があるものについて話したいと思います。以下で強調表示されている機能は DBA の観点からまとめられており、開発者の観点からの変更点をカバーする記事が間もなく公開される予定です。

アップグレードに関する注意事項

最初に、既存のセットアップからアップグレードするためのヒントをいくつか示します。9.6 以前から移行するときに問題を引き起こす可能性のある小さなことがいくつかあります。そのため、実際のアップグレードを行う前に、必ず別のコピーでアップグレードをテストしてください。考えられるすべての問題についてはリリース ノートを参照してください。最も顕著な欠陥は次のとおりです:

「xlog」を含むすべての関数は、「xlog」の代わりに「wal」を使用するように名前が変更されました。

後者の名前は通常のサーバー ログと混同される可能性があるため、これは「念のため」の変更です。サードパーティのバックアップ/レプリケーション/HA ツールを使用している場合は、それらが最新であることを確認してください。

サーバーログ (エラーメッセージ/警告など) を保持する pg_log フォルダーの名前が「log」に変更されました。

ログ解析または grep スクリプト (存在する場合) が機能することを必ず確認してください。

デフォルトでは、クエリは最大 2 つのバックグラウンド プロセスを使用します。

CPU の数が少ないマシンで postgresql.conf 設定のデフォルト値 10 を使用すると、並列処理がデフォルトで有効になっているため、リソース使用量が急増する可能性があります。これは良いことです。クエリの高速化。以前の動作が必要な場合は、max_Parallel_workers_per_gather を 0 に設定します。

デフォルトでは、ローカルホストのレプリケーション接続が有効になっています。

テストなどの作業を簡略化するために、localhost およびローカル Unix ソケット レプリケーション接続が pg_hba.conf の「trust」モード (パスワードなし) で有効になりました。したがって、他の非 DBA ユーザーが実稼働マシンにアクセスできる場合は、必ず構成を変更してください。

DBA の観点から見た私のお気に入り

論理レプリケーション

待望のこの機能では、単一のテーブル、テーブルの一部、またはすべてのテーブルのみをコピーする場合、パフォーマンスの低下を最小限に抑えた簡単なセットアップが必要です。これは、後続のメジャー バージョンをダウンタイムなしでアップグレードできることも意味します。これまでは (Postgres 9.4 が必要)、これはサードパーティの拡張機能または低速トリガーベースのソリューションを使用することで可能でした。私にとって、これがベスト 10 の機能です。

パーティションの宣言

パーティションを管理する以前の方法では、挿入を正しいテーブルに再ルーティングするためのトリガーの継承と作成が必要でしたが、パフォーマンスへの影響は言うまでもなく面倒でした。現在サポートされているのは、「範囲」および「リスト」パーティショニング スキームです。一部のデータベース エンジンで「ハッシュ」パーティショニングが不足している場合は、式で「リスト」パーティショニングを使用して同じ機能を実現できます。

利用可能なハッシュインデックス

ハッシュ インデックスは WAL に記録されるため、クラッシュ セーフになり、パフォーマンスが向上し、単純な検索では大規模なデータに対する標準の B ツリー インデックスよりも高速になります。より大きなインデックス サイズもサポートされています。

列間のオプティマイザー統計

このような統計は、値が実際に何らかの形で相互に依存していることを示すために、一連のテーブル列に対して手動で作成する必要があります。これは、返されるデータが非常に少ないとプランナが判断する低速クエリ (確率の積から得られる数値が非常に小さい場合が多い) に対処し、結果的に大量のデータでパフォーマンスが低下します (たとえば、「ネストされたループ」結合を選択するなど)。

レプリカ上の並列スナップショット

pg_dump で複数のプロセス (-jobs フラグ) を使用して、スタンバイ サーバーでのバックアップを大幅に高速化できるようになりました。

並列処理ワーカーの動作をより適切に調整する

max_Parallel_workers および min_Parallel_table_scan_size/min_Parallel_index_scan_size パラメーターを参照してください。後者の 2 つのデフォルト値 (8MB、512KB) を少し増やすことをお勧めします。

ツールを簡単に使用できる新しい組み込み監視ロール

新しいロール pg_monitor、pg_read_all_settings、pg_read_all_stats、および pg_stat_scan_tables により、以前はスーパーユーザー アカウントまたは SECURITY DEFINER ラッパー関数を使用して実行する必要があったさまざまな監視タスクを簡単に実行できるようになります。

より安全なレプリカ生成のための一時的な (セッションごとの) レプリケーション スロット

B ツリー インデックスの有効性をチェックするための新しい Contrib 拡張機能

これら 2 つのスマート チェックは、ページレベルの検証ではカバーされない構造的な不一致とコンテンツを検出します。近い将来、さらに深く掘り下げられることを期待しています。

Psql クエリ ツールが基本的なブランチ (if/elif/else) をサポートするようになりました

たとえば、次の例では、多数のバージョン固有のスクリプトではなく、特定のバージョン ブランチ (pg_stat* ビューなどの異なる列名を持つ) を持つ単一のメンテナンス/監視スクリプトが有効になります。

リーリー

今回はここまでです！もちろん、リストされていないものは他にもたくさんあるため、専任の DBA の場合は、リリース レコードをより包括的に確認することを強くお勧めします。このリリースに貢献してくれた 300 人以上の人々に感謝します。

以上がDBA が PostgreSQL の新たな問題を発見の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。