すべてのプロダクト
Search
ドキュメントセンター

Data Transmission Service:ApsaraDB RDS for MySQL インスタンスの文字セットのシームレスな変更

最終更新日:Jun 23, 2026

ビジネス要件を満たすため、テーブルの文字セットを変更する必要がある場合があります (例: gbk から utf8mb4 へ)。ALTER コマンドを直接使用すると、テーブルがロックされるため、テーブルが大きい場合にはサービスに大きな影響を及ぼす可能性があります。

このトピックでは、サービス中断を最小限に抑えながら、ApsaraDB RDS for MySQL インスタンスの文字セットを変更する方法について説明します。このプロセスでは、ターゲットインスタンスに新しい文字セットのテーブルスキーマを作成し、Data Transmission Service (DTS) を使用してソースインスタンスからデータを移行し、ロールバックソリューションまたはデュアルライトソリューションを実装してスムーズな移行を確実にします。

注意事項

  • 文字セットを変更する前に、アプリケーションと SQL ステートメントをテストし、新しい文字セットと互換性があることを確認してください。

  • 全量データ移行の実行中、DTS はソースインスタンスとターゲットインスタンスの両方で読み取りおよび書き込みリソースを消費するため、データベースの負荷が増加する可能性があります。開始前に、両インスタンスのパフォーマンスを評価し、オフピーク時間にデータ移行を実行することを検討してください。

  • ソースインスタンス上のテーブルにプライマリキーまたは一意制約がなく、列によって一意性が保証されない場合、移行によってターゲットインスタンスに重複データが発生する可能性があります。

ステップ1:テーブルスキーマのエクスポートとインポート

この例では、Data Management (DMS) 経由でアクセスされるすべてのインスタンスは、無料操作 管理および制御モードを使用します。

  1. ソースインスタンスから、文字セットを変更するテーブルのスキーマスクリプトをエクスポートします。

    1. DMS を使用してソースインスタンスにログオンします。詳細については、「DMS を使用して ApsaraDB RDS インスタンスにログオンする」をご参照ください。

    2. 上部のナビゲーションバーで、データベース開発 > データエクスポート > データベースのエクスポート を選択します。

      説明

      この操作を実行するには、まず右上隅の アイコンからアクセスできる設定メニューで トップドロップダウンメニュー を有効にする必要があります。

    3. エクスポート設定を構成します。

      説明

      必要なパラメーターと設定手順は、宛先インスタンスの管理モードによって異なる場合があります。 詳細については、「データベースのエクスポート」をご参照ください。

      設定

      説明

      [要求されたデータエクスポートカテゴリ]

      データベースのエクスポート を選択します。

      [データベース名]

      エクスポートするデータベースを選択します。

      説明

      データベースをエクスポートするには、必要な権限が必要です。 詳細については、「自分の権限の表示」をご参照ください。

      [輸出テーブル]

      この例では、部分テーブル が選択されています。 要件に応じて 部分テーブル または すべてのテーブル を選択できます。

      説明

      部分テーブル を選択した場合は、ページの右側でテーブルを選択し、フィルター条件を設定する必要があります。

      [輸出コンテンツ]

      コード構造 を選択します。

      [エクスポート形式]

      この例では、デフォルトで [SQL] が選択されており、変更できません。

      [構造タイプのエクスポート]

      ビジネス要件に基づいて、エクスポートするスキーマタイプを選択します。

      • [ストアドプロシージャ]

      • [関数]

      • [トリガー]

      • [ビュー]

      • [イベント]

      説明

      サポートされるスキーマタイプはデータベースの種類によって異なります。コンソールに表示されるオプションが正です。

      [その他のオプション]

      ビッグデータエクスポートオプション または Sqlスクリプト拡張オプション をクリックし、必要なオプションを選択します。

    4. 申請書の提出 をクリックし、チケットが承認されるのを待ちます。

    5. チケットが承認されたら、ダウンロード セクションで エクスポートファイルのダウンロード をクリックします。ダウンロードリンクは 24 時間有効です。この期間内にファイルをダウンロードしてください。

  2. ダウンロードしたファイルを解凍します。 次に、スキーマスクリプトを開き、文字セットの設定をターゲットの文字セットに変更します。

  3. ソースインスタンスと同じ仕様で新しい ApsaraDB RDS for MySQL インスタンスを購入します。 詳細については、「ApsaraDB RDS for MySQL インスタンスの作成」をご参照ください。

  4. 変更したスキーマスクリプトを新しい ApsaraDB RDS for MySQL インスタンスにインポートします。

    1. DMS を使用して新しい ApsaraDB RDS for MySQL インスタンスにログインします。 詳細については、「DMS を使用した ApsaraDB RDS インスタンスへのログイン」をご参照ください。

    2. 上部メニューで、データベース開発 > データ変更 > データインポート の順に選択します。

    3. インポート設定を構成します。

      説明

      必要なパラメーターと設定手順は、インスタンスの管理モードによって異なる場合があります。 詳細については、「データのインポート」をご参照ください。

      パラメーター

      説明

      [要求されたデータ変更カテゴリ]

      バルクデータのインポート を選択します。

      [データベース]

      インポート先のデータベース。

      説明

      無料操作 または 安定した変更 [管理および制御モード] のインスタンスの場合、データベースを選択する前にログインする必要があります。

      [ファイルエンコーディング]

      インポートファイルの文字エンコーディングを選択します:

      • UTF-8

      • GBK

      • ISO-8859-1

      • 自動検出

      [インポートモード]

      インポートモードを選択します。 次の 2 つのモードがサポートされています:

      • スピードモード:実行フェーズでは、システムはファイルを読み取り、宛先データベースで SQL ステートメントを直接実行します。 このモードはセキュリティモードよりも高速ですが、安全性は劣ります。

        説明

        デフォルトでは、スピードモード のセキュリティルールでは、スピードモード でのデータインポートは許可されていません。 この機能は、セキュリティルール > Sqlの変更 > 基本設定項目 で関連するセキュリティルールを有効にすることで使用できます。

      • セキュリティモード:事前チェックフェーズでは、システムはファイルを解析し、SQL または CSV データをキャッシュします。 実行フェーズでは、キャッシュから読み取り、宛先データベースでステートメントを実行します。 このモードはセキュリティが向上しますが、スピードモードよりも低速です。

      [ファイルタイプ]

      インポートするファイルの種類を選択します。

      • SQL スクリプト:セキュリティコラボレーションモードでは、デフォルトで INSERT および REPLACE コマンドタイプのみが許可されます。 DBA または管理者は、セキュリティルール > Sqlの変更 > バルクデータのインポート で設定を変更できます。

      • CSV:ファイル内の区切り文字はカンマである必要があります。

      • Excel:Excel ファイルには、ヘッダー (属性) またはデータのみを含めることができます。

      [添付ファイル]

      アップロードファイル をクリックして添付ファイルをアップロードします。

      説明
      • SQL、CSV、TXT、XLSX、ZIP 形式のファイルがサポートされています。

      • 最大ファイルサイズは 5 GB です。

      [その他のオプション]

      エラーを無視するかどうかを選択します。

      • 無視しない (未選択):デフォルト設定です。 エラーが発生した場合、システムは後続の SQL ステートメントの実行を停止し、エラーを報告します。

      • 無視する (選択):エラーが発生した場合、システムはそれを無視し、後続の SQL ステートメントの実行を続行します。

    4. 申請書の提出 をクリックします。 システムの事前チェックに合格するのを待ちます。 事前チェックが失敗した場合は、プロンプトに従って問題を特定して修正し、再度チケットを送信します。

      説明

      システムは、アップロードされた SQL スクリプトを事前チェックします。 CSV ファイルをアップロードすると、対応する INSERT ステートメントが生成されます。

    5. チケットが承認されたら、行う セクションで 変更の実行 をクリックします。

    6. タスク設定 ダイアログボックスで、チケットを実行するタイミングを選択します。 すぐに実行するかどうか を選択できます。 そうでない場合は、すぐに実行するかどうか スイッチをオフにして開始時刻を選択します。 次に、実行の決定 をクリックします。 ダイアログボックスには、[セキュリティ変更に関する注意] も表示されます:オフピーク時間帯に実行するようにしてください。

      実行方法は次のとおりです:

      • [即時実行]:デフォルト。 [実行の確認] をクリックすると、タスクはすぐに実行されます。

      • [スケジュール実行]:タスクの開始時刻を選択します。[実行の確認] をクリックすると、タスクは指定された時刻に自動的に実行されます。

      説明
      • 実行中、システムは解析された SQL をストリームで読み取り、データベースでバッチ実行します。各バッチのサイズは 1 MB です。

      • [実行] セクションで、タスクのステータス、SQL チェック詳細、スケジューリングログを表示できます。

      • 一時停止したタスクを再開した場合の動作は、インポートモードによって異なります:

        • スピードモード:スクリプトの実行またはデータファイルのインポートが最初から開始されます。

        • セキュリティモード:スクリプトの実行またはデータファイルのインポートが一時停止した時点から再開されます。

    7. インポートが成功したら、show create table <table_name>; コマンドを実行して、テーブルの文字セットを確認できます。

ステップ 2:新しいインスタンスにデータを移行する

  1. Data Transmission Service (DTS) コンソールにログインします。

    説明
    • Data Management (DMS) コンソールに自動的にリダイレクトされた場合は、右下隅のチャットボット jiqiren にある 返回旧版 アイコンをクリックして、以前のバージョンの DTS コンソールに戻ります。

    • 新しい DTS コンソールを使用している場合は、右下隅の 返回旧版 アイコンをクリックして、以前のバージョンに戻ります。

  2. 左側のナビゲーションウィンドウで、[データ移行] をクリックします。

  3. [移行タスク] ページの上部で、移行先クラスターが存在するリージョンを選択します。

  4. ページの右上隅にある [移行タスクの作成] をクリックします。

  5. 移行タスクのソースデータベースと移行先データベースを構成します。

    カテゴリ

    設定

    説明

    タスク名

    -

    DTS はタスク名を自動的に生成します。識別しやすいように、わかりやすい名前を指定してください。名前は一意である必要はありません。

    ソースデータベース

    インスタンスタイプ

    RDS インスタンス を選択します。

    インスタンスリージョン

    ソース RDS インスタンスが配置されているリージョンを選択します。

    RDS インスタンス ID

    ソース RDS インスタンスの ID を選択します。

    データベースアカウント

    ソース RDS インスタンスのデータベースアカウントを入力します。このアカウントには、移行するデータベースに対する読み取り権限が必要です。

    データベースパスワード

    データベースアカウントのパスワードを入力します。

    説明

    ソースデータベース情報を入力した後、データベースのパスワード の横にある 接続テスト をクリックして、情報が正しいかどうかを確認できます。情報が正しい場合、合格 というメッセージが表示されます。メッセージが 失敗 と表示される場合は、失敗 の横にある チェック をクリックし、表示される指示に従ってソースデータベース情報を調整してください。

    接続方法

    非暗号化 または SSL 暗号化 を選択します。SSL 暗号化 を選択する場合は、まず RDS インスタンスの SSL 暗号化を有効にする必要があります。詳細については、「SSL 暗号化の構成」をご参照ください。

    説明

    暗号化 設定は、中国本土のリージョンでのみ利用可能です。

    移行先データベース

    インスタンスタイプ

    RDS インスタンス を選択します。

    インスタンスリージョン

    移行先 RDS インスタンスが配置されているリージョンを選択します。

    RDS インスタンス ID

    移行先 RDS インスタンスの ID を選択します。

    データベースアカウント

    移行先 RDS インスタンスのデータベースアカウントを入力します。このアカウントには、移行先データベースに対する読み取りおよび書き込み権限が必要です。

    データベースパスワード

    データベースアカウントのパスワードを入力します。

    説明

    宛先データベース情報を入力した後、データベースのパスワード の後に 接続テスト をクリックして、入力した情報が正しいかどうかを確認できます。情報が正しい場合、合格 というメッセージが表示されます。メッセージが 失敗 と表示される場合は、失敗 の後に チェック をクリックし、表示される指示に従って宛先データベース情報を調整してください。

    接続方法

    非暗号化 または SSL 暗号化 を選択します。SSL 暗号化 を選択する場合は、まず RDS インスタンスの SSL 暗号化を有効にする必要があります。詳細については、「SSL 暗号化の構成」をご参照ください。

    説明

    暗号化 設定は、中国本土のリージョンでのみ利用可能です。

  6. 構成が完了したら、ページの右下隅にある [ホワイトリストに追加して次のステップに進む] をクリックします。

    説明

    このステップでは、DTS サーバーの IP アドレスが ApsaraDB RDS for MySQL インスタンスのホワイトリストに自動的に追加され、DTS サーバーがソースインスタンスと移行先インスタンスに接続できるようになります。

  7. 移行タイプとオブジェクトを選択します。

    設定

    説明

    移行タイプ

    ステップ 1 でスキーマ移行が完了しているため、ここではスキーマ移行を選択する必要はありません。

    • 完全移行のみを実行する場合は、フルデータ移行 のみを選択します。

      警告

      データの一貫性を確保するため、完全データ移行中はソースインスタンスに新しいデータを書き込まないでください。

    • ゼロダウンタイム移行の場合は、フルデータ移行[増分データ移行] の両方を選択します。

      説明

      増分データ移行フェーズ中にサポートされる SQL 操作は、INSERT、UPDATE、DELETE、CREATE TABLE、ALTER TABLE、RENAME TABLE、TRUNCATE TABLE、および DROP TABLE です。

    移行オブジェクト

    オブジェクトの移行 ボックスで、ステップ 1 でスキーマを移行したオブジェクトを選択します。次に、向右小箭头 アイコンをクリックして、選択中のオブジェクト ボックスに移動します。

    警告

    スキーマはすでに移行されているため、オブジェクト名のマッピングは実行しないでください。これを行うと、移行が失敗します。

  8. 移行タスクを開始します。

    1. ページの右下隅で、[事前チェックして開始] をクリックします。

      説明
      • DTS は移行タスクを開始する前に事前チェックを実行します。タスクは事前チェックに合格した後にのみ続行できます。

      • 事前チェックが失敗した場合は、特定のチェック項目の横にある 提示 アイコンをクリックして詳細を確認してください。プロンプトに基づいて問題を修正し、再度事前チェックを実行してください。

    2. 事前チェックに合格したら、次へ をクリックします。

    3. [設定の確認] ダイアログボックスで、インスタンスクラス を選択し、[Data Transmission Service (従量課金) 利用規約] チェックボックスをオンにします。

    4. 購入して起動 をクリックして、移行タスクを開始します。

Step 3: Perform the workload switchover

Perform the workload switchover using one of the following solutions, based on your business needs.

  • Rollback solution (no application changes required, but rollback may fail)

    1. Verify the migrated data in the destination ApsaraDB RDS for MySQL instance.

    2. Follow the procedure in the Workload switchover procedure document to switch your workload and establish a rollback plan. This involves migrating incremental data from the new destination instance back to the original source instance.

    3. Keep the reverse data migration task running for one business cycle. After the cycle, test all functionalities. If they work correctly, you can stop the reverse data migration task created for the rollback plan.

    4. Optional: If the source instance is no longer needed, you can release it (if it is a pay-as-you-go instance) or unsubscribe from it (if it is a subscription instance).

  • Dual-write solution (higher rollback success rate, but requires significant application changes)

    1. Modify your application to implement a dual-write logic, where data changes are written to both the source and destination instances simultaneously.

    2. Stop the data migration task.

      • フルデータ移行

        フルデータ移行中にタスクを手動で停止しないでください。 そうしないと、システムはすべてのデータを移行できません。 移行タスクが自動的に終了するまで待ちます。

      • 増分データ移行

        増分データ移行中、タスクは自動的に終了しません。 移行タスクを手動で停止する必要があります。

        1. タスクの進行状況バーに [増分データ移行][移行タスクは遅延しません] が表示されるまで待ちます。 その後、ソースデータベースへのデータの書き込みを数分間停止します。 場合によっては、進行状況バーに増分データ移行の遅延時間が表示されます。

        2. 増分データ移行のステータスが移行タスクが遅延なしに変更された後、移行タスクを手動で停止します。Stop a task during incremental migration

      説明

      You can log on to the source instance and run show processlist; to check session information and ensure that no new sessions are performing write operations.

    3. Verify the migrated data in the destination ApsaraDB RDS for MySQL instance.

    4. Configure your application for dual-write, where data changes are written to both the source and destination instances.

    5. Keep the dual-write state for one business cycle. After the cycle, test all functionalities. If they work correctly, you can adjust the application to write only to the destination instance.

    6. Optional: If the source instance is no longer needed, you can release it (if it is a pay-as-you-go instance) or unsubscribe from it (if it is a subscription instance).