私の本番データベースでは、アラート関連のテーブルはデフォルトのCharSetが「latin」で作成されています。これが原因で、テーブルに日本語の文字を挿入しようとするとエラーが発生します。テーブルと列のデフォルトの文字セットをUTF8に変更する必要があります。これらのテーブルには膨大なデータがあるため、Alterコマンドは非常に時間がかかり（同じ量のデータを使用するローカルDBでは5時間かかりました）、テーブルをロックするとデータが失われる可能性があります。データを失うことなく、CharsetをUTF8に変更するメカニズムを計画できますか？
巨大なデータテーブルの文字セットを変更するためのより良い方法はどれですか？
私はこれをmysqlマニュアルhttp://dev.mysql.com/doc/refman/5.1/en/alter-table.htmlで見つけました：
ほとんどの場合、ALTERTABLEは元のテーブルの一時的なコピーを作成します。MySQLは、テーブルを変更している他の操作を待ってから続行します。変更をコピーに組み込み、元のテーブルを削除し、新しいテーブルの名前を変更します。ALTER TABLEの実行中、元のテーブルは他のセッションで読み取ることができます。ALTER TABLE操作の開始後に開始されたテーブルへの更新と書き込みは、新しいテーブルの準備ができるまで停止され、更新が失敗することなく自動的に新しいテーブルにリダイレクトされます。
そうです。これを実行している間、ダウンタイムを最小限に抑えるのは難しいことです。テーブルの使用プロファイルによって異なりますが、読み取り/書き込みは他にもありますか？
私が考えることができる1つのアプローチは、ある種のレプリケーションを使用することです。したがって、UTF-8を使用する新しいアラートテーブルを作成し、可用性/スループットに影響を与えることなく、元のテーブルを新しいテーブルに複製する方法を見つけます。レプリケーションが完了したら（または十分に閉じたら）、名前を変更してテーブルを切り替えますか？
もちろん、これは口で言うほど簡単ではありません。可能であれば、さらに学習する必要があります。
Percona Toolkit :: online-chema-changeツールを調べることができます：
pt-online-schema-change
これはまさにこれを行います-「読み取りまたは書き込みをブロックせずにテーブルの構造を変更します」-いくつかの制限があります（InnoDBテーブルのみなど）それに伴うリスク。
レプリケーションの問題を設定するときに、他のマシンまたはインスタンスにデータベースのレプリケートされたコピーを作成し、スレーブコマンドを停止してテーブルを変更します。複数のテーブルがある場合は、各会話の間に、2つのデータベースを同期するためにスレーブを再発行することを検討できます。（これを行わないと、同期に時間がかかる場合があります）変換が完了すると、複製されたコピーによって古い本番データベースが置き換えられ、古いデータベースが削除されます。これは、ダウンタイムを最小限に抑えるために私が見つけた方法です。