DBスキーマの変更に伴い、実動システムがダウンする可能性がある人はどうですか？何らかの制約（例えば一意性制約）が加わるとアプリケーションを変更するのが困難になり、dbも同時に変更する必要があると思われます。そうでなければ、データやアプリケーションのいずれかでエラーが発生します。dbスキーマのダウンタイムがゼロ（またはゼロに近い）
私は、おそらくスレーブdb（mysqlレプリケーションを使用して）に切り替えて、マスターでスキーマの変更を実行することを考えましたが、マスターに適用されていないスレーブに適用された更新クエリを、バックアップサーバーを持たないという危険性があります。
人々はこれらの問題を回避するためにどのような手法を使用していましたか？
おかげで、 マニッシュ
私はあなたのアイデアに近いだと言うだろう。効果的には、私はマスターとスレーブを持ち、マスターはライブであり、スレーブはそれに複製されています。スレーブでレプリケーションを一時停止してからスレーブでスキーマの変更を実行し、スキーマの変更が完了したらレプリケーションのポーズを解除します。そのプロセス全体が完了したら、レプリケーションされた変更がスレーブ上でフラッシュされることを確実にするためにマスターを非常に短時間停止させてから、マスターとスレーブを切り替えます。それはあなたが必要とするものを行うはずです。
これは、スキーマに対する変更が保留中のレプリケーションコマンドによって変更されていない場合にのみ有効であることに注意してください。これは一般に、衝突が起こりそうにないことを保証するためにトラフィックが少ない時間に最もよく行われます。スレーブがスキーマを完全に更新して変更を複製するまで、マスターに変更を加えることはないので、マスタでは非常に安全です。
どのようにスキーマを変更するかによって、以前に実装されたスキーマの変更が以前のバージョンのアプリケーションと下位互換性があることを確認しようとしました。これはマイナーな（そしてかなりメジャーな）プロジェクトにはうまくいきました。また、アプリケーションに重大なパフォーマンス上の問題があった場合（思考を壊滅させた場合）、コードをロールバックするのは簡単ではなく、簡単な作業でした。
この問題を回避するには、クラスタデータベースまたはマスター/スレーブを提案するのが唯一の方法です。通常、1つのノードをオフラインにしてアップグレードを実行します。これが完了すると、通常、現在のマスターから新しくアップグレードされたシステムに同期を実行し、古いスキーマのデータを新しいスキーマに変換する方法を理解します。 （同期中に、マスターは一時的に読み取り専用モードになることがあります）
次に、マスター/スレーブの役割を切り替えて、他のデータベーススキーマをアップグレードします。それらをバックアップして、アップグレードしたスレーブをオンラインに戻してください。
実際には、特に重要なスキーマ変更がある場合は、これを正しく実行するのは非常に難しい場合があります。