- Geoを動かすための最低条件は?
- Geo はどのプロジェクトを同期させるか、どうやって知るのですか?
- Geo を災害復旧に使用できますか?
- セカンダリ・ノードにはどのようなデータがレプリケートされますか?
- セカンダリー・ノードに
git push
。 - セカンダリノードにコミットがレプリケートされるまでにどのくらい時間がかかりますか?
- SSH サーバーが別のポートで動作している場合はどうなりますか?
- セカンダリノードのDockerレジストリを、プライマリノードのものをミラーするように設定することは可能ですか?
Geo よくある質問
Geoを動かすための最低条件は?
要件はインデックスページに記載されています。
Geo はどのプロジェクトを同期させるか、どうやって知るのですか?
各セカンダリノードには、GitLabデータベースの読み取り専用の複製があります。セカンダリノードには、どのプロジェクトが同期されたかを保存するトラッキングデータベースもあります。 Geoは2つのデータベースを比較して、まだトラッキングされていないプロジェクトを見つけます。
最初は、このトラッキングデータベースは空なので、GeoはGitLabデータベースで見ることができるすべてのプロジェクトから更新しようとし始めます。
各プロジェクトを同期します:
- Geo は
git fetch geo --mirror
を発行し、プライマリノードから最新の情報を取得します。変更がない場合、同期は高速に行われ、すぐに終了します。そうでない場合は、最新のコミットをプルします。 - セカンダリノードはトラッキングデータベースを更新し、プロジェクトA、B、Cなどを同期したことを保存します。
- すべてのプロジェクトが同期されるまで繰り返します。
誰かがプライマリノードにコミットをプッシュすると、GitLab データベースにリポジトリが変更されたというイベントが発生します。セカンダリノードはこのイベントを見て、問題のプロジェクトをダーティとしてマークし、プロジェクトを再同期するようスケジュールします。
パイプラインの問題 (たとえば、同期が何度も失敗したり、ジョブが失われたりした場合) によってプロジェクトの同期が永久に停止しないように、Geo はダーティとマークされたプロジェクトがないか追跡データベースを定期的にチェックします。このチェックは、同時同期数がrepos_max_capacity
を下回り、同期を待機している新しいプロジェクトがない場合に行われます。
Geo にはチェックサム機能もあり、すべての Git 参照の SHA 値を SHA256 で合計します。プライマリノードと セカンダリノードで参照が一致しない場合は、セカンダリノードがそのプロジェクトをダーティとしてマークし、再同期を試みます。 そのため、たとえ追跡データベースが古かったとしても、検証が有効になってリポジトリの状態の不一致が見つかり、再同期されるはずです。
Geo を災害復旧に使用できますか?
はい、しかしレプリケートされるデータには制限があります(セカンダリ・ノードにレプリケートされるデータとはを参照)。
ディザスタリカバリのドキュメントをお読みください。
セカンダリ・ノードにはどのようなデータがレプリケートされますか?
現在、プロジェクトリポジトリ、LFSオブジェクト、生成された添付ファイル/アバター、データベース全体をレプリケートしています。 つまり、ユーザーアカウント、イシュー、マージリクエスト、グループ、プロジェクトデータなどがクエリ可能です。
セカンダリー・ノードに git push
。
はい!セカンダリノードへの直接プッシュ(HTTPとSSHの両方、Git LFSを含む)はGitLab Premium11.3で導入されました。
セカンダリノードにコミットがレプリケートされるまでにどのくらい時間がかかりますか?
すべてのレプリケーションオペレーションは非同期であり、ディスパッチされるためにキューに入れられます。 したがって、トラフィック量、コミットの大きさ、ノード間の接続性、ハードウェアなど、多くの要因に依存します。
SSH サーバーが別のポートで動作している場合はどうなりますか?
プライマリノードからすべてのセカンダリノードへリポジトリの変更をフェッチするためにHTTPを使用しています。
セカンダリノードのDockerレジストリを、プライマリノードのものをミラーするように設定することは可能ですか?
セカンダリノードについては、Dockerレジストリを参照してください。