Bitbucket Data Center で整合性チェックを実行する
整合性チェックの実行
To run integrity checks, add this line to your ${BITBUCKET_HOME}/shared/bitbucket.properties:
disaster.recovery=true次に、Bitbucket を起動します。必要に応じ、すべてのクラスタ ノードで Bitbucket を起動できます。
起動時、Bitbucket は 1 つのクラスタ ノードでのみ整合性チェックを実行します。整合性チェックには数分かかる場合がありますが、これはバックグラウンドで実行されます。整合性チェックの実行中でもユーザーは引き続き、ログイン、システムの操作、およびリポジトリでのホスト操作を実行できます。
整合性チェックの無効化
After you have restored Bitbucket, integrity checks have run, and you have resumed normal operation, turn off the disaster.recovery property in your bitbucket.properties file so integrity checks won't run unnecessarily the next time your instance is restarted.
disaster.recovery=false整合性チェックで確認される内容
Integrity checks (which run when disaster.recovery is set to true) scan your instance for inconsistencies between the database and home directory that can occur when snapshots of your database and file system were taken at slightly different times.
整合性チェックが必要な理由
Bitbucket の実行中、データベースとホーム ディレクトリには絶えず変更が加えられますが、ほぼすべての状況において 2 つのデータ ソースは互いに一致します (UI が低速な場合も含む)。
ただし、データベースとホーム ディレクトリのスナップショットが個別に取得され、データベースとホーム ディレクトリに影響を与える更新が 2 つのスナップショット間で発生した場合、整合性チェックで不一致が検出される場合があります。これが発生する場合の例として、スナップショット間でプル リクエストがマージされた場合があります。データベースとホーム ディレクトリのスナップショットを十分に近いタイミングで取得すると、不一致が発生する可能性は低くなります。
整合性チェックで検出できないもの
Git の不一致: 整合性チェックはリポジトリ内の不一致ではなく、データベースとホーム ディレクトリとの間の不一致のみを検出します。
If you suspect repositories in your Bitbucket instance have become corrupted in some other way, you may need to manually run git fsck to diagnose and restore individual repositories. See Recommended action plan if a repository becomes corrupted on a Bitbucket Server for more information, or contact Atlassian Support.
バックアップ取得時にデータベース / ホーム ディレクトリ内に情報がない: 整合性チェッカーはデータベースとファイル システムのリポジトリまたはプル リクエストの状態の不一致を検出し、整合性を復元するための調整を行うことはできますが、バックアップの作成時にデータベースまたはホーム ディレクトリ内に存在しなかった情報を再構築することはできません。
つまり、バックアップを 1 時間ごとに作成している場合、最新のバックアップから復元すると、ユーザーの 1 時間分の作業が失われる可能性があります。さらに、データベースとファイル システムの最新のスナップショットが 1 分違いで取得された場合、この時間にプル リクエストに加えられた変更は失われる可能性があり、整合性チェッカーで再構築することはできません。
バックアップで不一致が発生するのを防ぐ最適な方法は、ファイル システムとデータベースのスナップショットをできるだけ近いタイミングで取得するか、データベース ベンダーの "ポイントインタイム リカバリ" 機能を使用して、データベースをファイル システムのスナップショット取得時点に復元することです。
整合性チェック プロセスからのフィードバック
システム管理者に整合性チェック プロセスの状態や結果を知らせる警告 
または情報 
バナーが表示されます。このバナーは次の 4 つのうちいずれかになります。
- 整合性チェックを実行中で、不一致は見つかっていない
- 整合性チェックを実行中で、1 つ以上の不一致が発見された
- 整合性チェックが完了し、不一致は見つからなかった
- 整合性チェックが完了し、不一致が発見された
整合性チェックによって不一致が見つかった場合
整合性チェックでデータベースとホーム ディレクトリの間に不一致が見つかった場合は、自動調整が実施され、2 つの間の整合性を復元します。たとえば、バックアップ プロセス中に、データのスナップショット後かつファイル システム のスナップショット前に誰かがプル リクエストをマージしていて、そのバックアップが復元されたとします。この場合、整合性チェックはプル リクエストが不一致状態にあることを検出し、データベースのプル リクエストを調整してディスク上の実際の状態と一致させます。これが発生すると、調整内容がプル リクエストの [アクティビティ] タブ内に表示され、整合性チェッカー サービス ユーザーに関連付けられます。整合性チェッカーによって実行された、プル リクエストに対する任意のアクティビティは、通常の通知を生成します。
[アクティビティ] タブでの整合性チェッカーによって行われた調整の例
整合性チェッカーは、不一致を確認するたびにアプリケーション ログにメッセージを書き込みます。atlassian-bitbucket.log を DefaultIntegrityCheckReporter でフィルタリングすると、関連するすべてのエントリが返されます。
整合性チェッカーのログ エントリを読むと、不一致の発生理由を確認できます。不一致のエラー メッセージは次のようになります。
The repository PROJ/repo[1] exists but the directory /repositories/1 is missing. To restore integrity, an empty repository directory was created.または
PROJ/repo[1]: Pull request #1 is marked merged but the merge commit could not be found on the target ref. Trying to restore integrity by reopeningまたは
PROJ/repo[1]: Pull request #1 could not be reopened, declining instead. (Reason: REASON)
ここで、REASON は次のいずれかになります。
- 同じ参照元 / 参照先を持つオープンなプル リクエストがすでに存在する
- 予期しないコミットの欠落
- fromRef を解決できない
広い時間範囲で多くの不一致が見つかった場合、データベースとホーム ディレクトリのスナップショットが、意図していたよりも離れたタイミングで取得されている可能性があります。このような不一致が発生しないよう、ディザスタ リカバリ プランを定期的にテストし、バックアップおよび復元プロセスがデータベースとホーム ディレクトリのスナップショットをできる限り近いタイミングで作成するようにします。
リスコープによって更新されたプル リクエスト
Bitbucket サーバーの標準のリスコープ プロセスは、大量のプル リクエスト不一致を標準化します。この場合、整合性チェック レポーターはアプリケーション ログにメッセージを記録するのではなく、すべてのプル リクエスト コラボレーターに通知を送信します。
シナリオの例
"整合性チェッカー" が検出および解決できるいくつかのシナリオの例を紹介します。
| 整合性チェック | ファイル システムの状態 | データベースの状態 | 結果 |
|---|---|---|---|
| 最近マージされたプル リクエスト | プル リクエストがマージされている | プル リクエストが "オープン" としてマークされている | "整合性チェッカー" はプル リクエストをリモートでマージされているとマークします。 注: マージ アクティビティのみが "整合性チェッカー" ユーザーに関連付けられ、マージ コミットの作成者は引き続き元のマージ作成者になります。 |
| プル リクエストがマージされていない | プル リクエストが "マージ済み" としてマークされている | "整合性チェッカー" によりプル リクエストが再オープンされます。 | |
| リポジトリ作成 | リポジトリ #2 が存在しない | リポジトリ #2 が存在する | ファイル システム上に空のリポジトリが作成されます。 |