web-dev-qa-db-ja.com

GlusterFSジオレプリケーションの再同期

WANで区切られた2台のサーバーを使用して、約1TBのデータを複製しています。

マスター側には、データを書き込む他の多くのサーバーにエクスポートされたGlusterボリュームを備えた単一のサーバーがあります。

スレーブ側には、Glusterボリュームが読み取り専用共有としてディザスタリカバリサーバーにエクスポートされた単一のサーバーがあります。

時間の経過とともに、スレーブはマスターと200 GBのチューニングで同期しなくなり、存在するはずのファイルは存在せず、削除されたファイルは同期します。これにはあまり一貫性がないようです。

クラスターにスレーブ上のすべてのファイルをチェックサムし、必要に応じて再複製するように強制する最も簡単な方法は何ですか？

ドキュメントは次のことを示唆しています。

説明：GlusterFSジオレプリケーションはデータを完全に同期しませんでしたが、ジオレプリケーションステータスはOKと表示されます。

解決策：インデックスを消去してGlusterFS Geo-replicationを再起動することにより、データの完全同期を強制できます。再起動後、GlusterFS Geo-replicationはすべてのデータの同期を開始します。つまり、すべてのファイルがチェックサムによって比較されます。これは、主に大規模なデータセットで、時間のかかる/リソースの高い使用率の操作になる可能性があります（ただし、実際のデータ損失）発生しません）。エラー状態が続く場合は、Glusterサポートに連絡してください。

ただし、このインデックスがどこにあるかについては言及していません。

#   gluster volume geo-replication share gluk1::share stop
Stopping geo-replication session between share & gluk1::share has been successful
# gluster volume set share geo-replication.indexing off
volume set: failed: geo-replication.indexing cannot be disabled while geo-replication sessions exist

このインデックスシャットオフは、接続がまだ存在している間は失敗し、ドキュメントにはこの要件が記載されていません。

助言がありますか？

glusterfs
3
Antitribu

GlusterFS Geo-Replicationはnotであり、災害復旧（読み取り専用）ではなく、複数の変更データプール（分散FS）を対象としているため、スレーブが同期しなくなりました。バックアップ）。

要するに、ジオレプリケーションはマスター/スレーブモデルであり、マスターサイトのみが書き込み/変更をプッシュし、変更は定期的にリモートに同期されます読み取り専用スレーブ。

真の分散複製ファイルシステムを作成するには、GlusterFSの「複製ボリューム」機能を使用する必要がありました。欠点は、現在のレプリケーションスキームでは、書き込みが強制的に同期されることです。これは、WANリンク間でレプリケートする場合、ローカルのLAN内書き込みでさえも同じくらい遅くなることを意味します。 WANパス。この制限を克服するために、 " 新しいスタイルのレプリケーション "を含めることを検討していますが、まだ実装されていないようです（少なくとも安定したエンタープライズでは）分布）。

現在の状況に戻ると、あなたは古典的な「スプリットブレインシナリオ」にあり、何ができるかわかりません。マスターとスレーブは、基になるボリュームに対して異なるビューを持っており、おそらく同じものに対して異なる互換性のない変更を蓄積しています。ファイル。私はあなたが（多かれ少なかれ）手動でそれらをレビューしなければならなかったと思います...

3
shodanshok