ダウンタイムを発生させることなく、本番環境のコードベース/データベーススキーマをどのように更新しますか？
ダウンタイムを発生させることなく、本番サーバーのコードベース/データベーススキーマを更新するためのテクニックは何ですか？
一般に、私がこれまでに取り組んだWebサイトは、この種の要件があり、すべてロードバランサーの背後にあるか、フェイルオーバーの場所が別々でした。このサンプルでは、1つのロードバランサー、2つのWebサーバー（A＆B）および2つのデータベースサーバー（M＆N-通常、DBサーバーはログシッピングを介してリンクされています-少なくともSQL Serverの世界では）があると仮定します。 ）。
- ロードバランサーから切断するWebサーバーA（すべての受信トラフィックがBに送られる）。
- ログ配布が停止します（DBサーバーMが最初に更新されます）。
- WebサーバーAを更新します。構成をDBサーバーMにポイントします。
- 更新が機能したことをテストして確認します（通常、人々は直接IPアドレスにアクセスしています）。
- 既存のセッションが引き続きBに移動するようにロードバランサーを設定します。新しいセッションはAに移動します。
- Bでのすべてのセッションが期限切れになるまで待ちます（30分以上になる可能性があります。通常、トラフィックを監視し、1時間の休憩が予定されています）。
- BとNを更新します。
- 更新が機能したことをテストして確認します。
- ログ配布を再度セットアップし、機能することをテストします。
- ロードバランサーを通常の動作に設定します。
非常に複雑なWebアプリケーションでは、ステップ1〜5として説明するのは一晩中かかり、時間と緊急連絡先番号を含む50ページのExcelスプレッドシートになる場合があります。このような状況では、システムの半分を更新する予定が午後6時から午前6時に予定されていますが、ユーザーはシステムを利用できます。 DRサイトの更新の処理は通常、翌日の夜に予定されています-初日に支障がないことを願っています。
アップタイムが必要な場合、パッチは最初にQA環境でテストされます。QA環境は、理想的には本番環境と同じハードウェアです。混乱が見られない場合は、通常の週末に適用される定期的なスケジュールで適用できます。
一般的なデータベース（Oracleなど）では、クエリを並行して実行しながらデータベーススキーマを変更できます。ただし、事前の計画が必要です。
それらは適用される変更のためのいくつかの制約です：
- 既存のコードで機能する必要があります。つまり、コードはスキーマの古いバージョンと新しいバージョンの両方を処理する必要があります
- トランザクションが急停止してDBにかかる負荷が発生しないようにする必要があります（私はあなたを見ています
CREATE INDEX） - データが失われるべきではありません（テーブルを削除して再作成することはできません）
スキーマに下位互換性を持たせるために、通常は列を追加または変更できます。既存のコードがそれを使用しない場合にのみ、何かを削除できます。
コードが透過的に変更を処理できない場合は、データベースを変更する前にコードを変更してください。
フォワードプランニングに関する簡単なアドバイス：DBリクエストでは常に列名を明示してください（SELECT * FROMは使用しないでください）。これにより、古いリクエストに新しい列が表示されなくなります。
すべてのシステムで可能なわけではありません。それをサポートする方法でセットアップする必要があります。
たとえば、数年前にアップグレードを支援した主要なシステムの1つは、24時間年中無休で利用できるはずです。これは、オフサイトのユーザーインターフェイス層とビジネス層の間の純粋な通信層を含む複数の層で構成されていました。通信層のコーディング方法により、ビジネス層またはDBスキーマへの将来の変更は、実際に停止することなく実装できます。最悪のシナリオでは、変更が有効になると、ユーザーは10〜30秒の一時停止を経験します。
変更がビジネス層への純粋なコード変更であった場合、それらはキューに入れられ、ミリ秒の遅延で「循環」する可能性があります。
次の理由でこれを行うことができます。
- 通信層はメッセージを保持できます。これにより、UIを停止する必要なく、UIレイヤー以外の層で実際に停止することができました。
- niData と呼ばれるMVDBによって処理されるビジネスレイヤー。これにより、すべてのコードがメモリに保持されます。コードをコンパイルした後、コマンドを使用して新しいオブジェクトコードをメモリに強制的に入れ、古いものを置き換えることができます。
他の手法には、既存のシステムの別のミラーへのトランザクションの複製が含まれます。更新を1つに適用することにより、更新と切り替えの間で行われたすべてのトランザクションを切り替えて再生します。 YMMVはシステムによって異なります。
これは、組み込みデータベースシステムと組み込みシステムの世界とは異なる視点です。組み込みシステムには、さまざまなネットワーク/テレコミュニケーションインフラストラクチャ機器が含まれ、この領域では、99.999％（ファイブナイン）の稼働率がよく言われます。
私たち（McObject）は、eXtremeDB High Availabilityを含む、組み込みデータベースシステム製品のeXtremeDBファミリのベンダーです。
まず、「組み込みデータベース」とは、データベースシステムが、コンパイルされてアプリケーションコードにリンクされるライブラリであることを意味します。その意味で、アプリケーションに「埋め込まれています」。
EXtremeDB高可用性では、アプリケーションのMASTERインスタンス（1つまたは複数のプロセスである場合があります）と、アプリケーションの1つ以上のREPLICAインスタンスがあります。レプリカがマスターへの接続を確立すると、「初期同期」と呼ばれるプロセスを通じてマスターのデータベースのコピーを受け取ります。これは、マスターアプリケーションが作業を継続している間に行うことができます。同期されると、レプリケーションを介してマスターのトランザクションを受け取ります。したがって、レプリカには常に最新のデータがあり、マスターに障害が発生した場合に（フェイルオーバーと呼ばれるプロセスを通じて）引き継ぐことができます。
初期同期の1つの機能は、「バイナリスキーマの進化」と呼ばれます。平易な英語では、これはレプリカのデータベースにデータを取り込むプロセスがレプリカのデータベーススキーマとマスターのデータベーススキーマの違いに対応することを意味します。
実際には、これは、アプリケーションの新しいバージョン（新しい/ドロップされたテーブル、新しい/ドロップ/変更されたフィールド、新しい/ドロップされたインデックスを使用）を構築し、その新しいバージョンのアプリケーションをマスターにアタッチして、新しいレプリカになる新しいレプリカ（つまり、新しいレプリカに強制的にフェイルオーバーして、レプリカがマスターになり、古いマスターがシャットダウンする）。これで、システムの可用性を妨げることなく、アプリケーションをバージョンNからN + 1に移行できました。これで、古いマスターと他のレプリカをバージョンN + 1にアップグレードできます。