web-dev-qa-db-ja.com

既存のPostgreSQLサーバーにSSDを継続的に追加する

PostgreSQL 11.2サーバー（TimescaleDB拡張機能付き）の実行専用のUbuntu 18.04サーバーは、すぐにディスク領域が不足するため、増大するデータベースサイズをサポートするには、新しいSSDディスクをマシンに追加する必要があります。

データは同じ/より高い速度で増加し続けると予想されるため、マシンが2.5インチドライブベイを使い果たすまで、ストレージハードウェアを継続的に増加する必要があります。そのため、複数のマシンにデータベースを分散することは考慮されます。複雑さが増します。

考え

  1. mergerfsのようなユニオンファイルシステムは、ドライブを一緒にプールして、ストレージ拡張の問題を簡単に解決できます。しかし、これはデータベース操作のレイテンシを増加させるため、 推奨されません 。冗長性は、基盤となるRAID-1/5/6/10を使用するか、SnapRAIDを使用して追加できます。

  2. RAID-0およびRAID-10では、RAIDアレイを新しく追加されたドライブに拡張でき、ストライピングによってパフォーマンスが向上するというボーナスがあります。ただし、追加されるすべてのドライブは、追加の障害ポイントです。さらに、SSDのミラーリングは用途が限定的であると多くの人が主張しています RAID-0の両方のSSDは同時に失敗する可能性が高いです 。つまり、これはおそらくRAID-10がRAID-0よりも優れていないことを意味します。さらに、SSDを追加するたびに、故障率は直線的に増加します。

  3. RAID-5/6は、パリティ計算と2つのドライブへの書き込みがあるためパフォーマンスを低下させ、 有効なIOPSを75％ 低下させます。データベースには適さないようです。

  4. PostgreSQL TABLESPACESを使用して、すべてのテーブルを特定のドライブに割り当てることができます。ただし、 テーブルスペースを使用すると、リカバリが非常に複雑になります 。さらに、新しいドライブに新しいテーブルスペースを作成して、Postgresに新しいレコードを書き込む場所を自動的に決定させることは可能ですか？

  5. ZFS、BTRFS？それらに精通していない、彼らが適しているかどうかを探求する用意がある。

質問：PostgreSQLマシンのストレージを拡張するために2020年に推奨される方法は何ですか？ ）、パフォーマンスに大きな影響を与えるべきではありません。また、リカバリがそれほど複雑であって、データが失われることはありませんか？

RAID-10は私にとっては良い考えのように思えますが、RAID-1は使用が制限されているように見えますが、ディスク容量の半分の「損失」を引き起こし、ドライブ数の増加に伴う障害点の増加により悪化します。

予算の制約により、2Uシャーシの16個のドライブベイすべてを一度にSSDで埋めることはできないため、段階的に行う必要があります。

アドバイスは大歓迎です！

EDIT：ZFSを調べたところ、これが私のケースの解決策の1つであるように思われます。

  • ミラーリングされたZFS vdevs（vdevごとに2つのドライブ）のみを含むZFSプールは、一度に2つのドライブを追加することでストレージプールの拡張を可能にします

  • 1つまたは2つのホットスペアをZFSプールに保持すると、ドライブの1つが故障したときにZFSによる自動フェイルオーバーが可能になります。

  • ミラーリングされたvdevを使用すると、ドライブが故障した後の再構築時間は、RAIDZ vdevを使用した場合よりもはるかに速くなります。これにより、再構築に使用された残りのドライブがプロセス中に失敗する可能性も減少します。劣化したミラー化されたvdevは、再構築中に、劣化したRAIDZ vdevよりもはるかに高いパフォーマンスを発揮します

  • ZFSはインラインデータ圧縮をサポートします。これにより、TimescaleDBデータのストレージ要件が大幅に軽減され（4X圧縮）、圧縮されていない限り圧縮データの更新を防ぐネイティブのTimescaleDB圧縮を使用する必要がありません。 TimescaleDBは、InfluexDBなどの他のデータベースと比較してデータ圧縮が不十分であることが知られているため、これも非常に重要です。

  • jjanesによって提案されているように、障害が発生しそうなときにSSDを監視して交換します

これを正しく理解していれば、ZFSミラー化されたvdevを使用すると、すべてのボックスがチェックされます。ドライブを継続的に追加し、単一のマウントポイント、データ冗長性、および最大4倍のデータ圧縮を提供するドライブプールを許可します。

postgresqltablespacesscalabilityraidtimescaledb
4
Nyxynyx

V1.5以降で利用可能なTimescaleDBのネイティブ圧縮を確認しましたか？上記のZFS/BTRFSについて言及するようにb/cにお願いします。これは、その圧縮をまだ使用していないことを示唆しています。

通常、実際に90〜98％のストレージ節約が見られます...

https://docs.timescale.com/latest/using-timescaledb/compression

さらに、TimescaleDBのattach_tablespaceコマンドを使用してディスクを追加すると、新しいチャンクが使用可能なテーブルスペース全体で負荷分散されます。

https://docs.timescale.com/latest/api#attach_tablespace

3
Mike Freedman