Rails アプリで、完了するまでに時間がかかる移行があります。最初に列のデフォルトを更新し、次に Solr インデックスを再インデックス化します。問題は、移行の実行中に、アプリの古いバージョンが部分的に新しいデータベースと solr インデックスを使用してリクエストを処理することです。また、新しいデフォルト列のために、いくつかのエラーがスローされます。
このような動作を回避するためのベストプラクティスの方法はありますか? 2 番目のデータベースと solr インデックスを使用する必要がありますか? カピストラーノで展開しています。
これは、長期にわたる複雑な Rails データベースの移行でよくある問題です。
いくつかの方法があります:
(1) データベースの移行を実行する前に、Web トラフィックをメッセージのあるページにリダイレクトします。これにより、データベースが部分的にしか移行されていない状態で、リクエストが入ってアプリケーションにヒットするのを防ぐことができます。ダウンタイムのため、これは理想的ではありません。
(2) コードをデプロイする前にデータベースの移行を実行しますが、データベースに後方互換性と前方互換性があることを確認してください。次に、コードをデプロイして新しいスキーマを使用します。「ロールバック」が必要な場合に備えて、古いスキーマにも (次のリリースまで) 書き込むことができます。その後、別の移行で列を削除または名前変更して、スキーマをクリーンアップします。これは、「ゼロ ダウンタイム データベース移行」と呼ばれます。
(3) 2 つのデータベースを持つことができ、新しいデータベースの準備ができたら、切り替えを行うことができます。ただし、ここでの問題は、アプリケーションから頻繁に書き込みが行われる場合に、同期を維持する方法です。スクリプトを実行して、後でそれらを同期できます。
予防措置として、ロールバックが必要になった場合に備えて、移行の前にデータベースのバックアップ ダンプを作成する必要があります。一部のデータベース移行は元に戻すことができないため、たとえば、列を削除します。または、影響を受けるテーブルをバックアップとして一時テーブルにコピーすることもできます。
そしてもちろん、移行は比較的静かな時期に行ってください。
solr の場合、エラーをスローすることなく増分更新を処理する必要があります。