テーブルロックなしでテーブルを変更

24時間365日動作するプロジェクト、mysqlデータベースを使用するプロジェクト、および典型的な状況を想像してください。開発者は次のように言います。 現在3億行あるタブレットでは、フィールドとインデックスを追加するのを忘れて、作業を停止しましたベースは受け入れられません、何かを考えてください。



トピックでグーグルしようとすると、2番目のプレートを作成し、そこにデータを徐々にコピーし（「S select OFFSETからT select *に挿入」）、テーブルの名前を変更するヒントがほとんどありますが、そのようなメカニズムには、たとえば元のテーブルのデータなどの重大な欠点がありますコピー後すぐに変更される場合があります。 書き込みのためにテーブルをロックすることは不可能であり、データの整合性が問題になります。



すべての変更を同期して2つのテーブルに入れて、外部コードを使用してデータをコピーし、古いものから新しいものへの未読のみを読み取ることができますが、これにはアプリケーションコードの変更が必要です。



外出先でそのような変更を行える条件はありますか？ 確かにそうです、それらのいくつかがありますが、私は真空で私の球形の馬のための1つのオプションだけを教えます。



指定-マスター複製マスターとコード内でアクティブなmysqlインスタンスを示す外部メカニズム（haproxy、application configなど）を備えた2台のサーバー上のmysqlデータベース。 つまり サーバー間でリクエストを切り替えることができます。

双方向レプリカ：



server1 <==> server2

server1は論理マスターです。 アプリケーションコードからリクエストを受け取ります。



1. server1でスレーブを無効にします（ mysql> stop slave; ）。 なぜなら サーバー2への要求がない場合、この方向でレプリカを無効にしても、両方のサーバーでデータの整合性が損なわれることはありません。

2. server2でalterを実行します。この要求はserver2でのみテーブルをロックしますが、prodはこれにアクセスせず、問題を引き起こしません。つまり安全です。

3.マスターからserver2へのバックログ、show slave statusコマンドを監視します。 Seconds_Behind_Masterに注意してください。 遅延は、変更中にロックされたテーブルへのクエリがserver2スレーブで再生されず、replay-logに蓄積され、変更後に再生されるという事実によって引き起こされます。

4.次に、server1で古いテーブルを取得し、server2で必要な新しい形式のテーブルを取得します。論理マスターをserver2に切り替える必要があります。

5. mysqladmin startなどを使用して、server1 leivaをオフにします。 これは、alterがserver2からserver1に送られ、そこでテーブルを変更するという事実につながります。

6.念のため、server1がレプリカに追いつくのを待ちます。 必要に応じて、論理マスターを再度切り替えます（たとえば、server2からバックアップを削除するためのハードコードがあり、論理マスターのバックアップが遅くならないように、切り替える必要があります）。



そして、そのような問題をどのように解決しますか？