ApsaraDB RDS MySQL は、2019 年 8 月 1 日から TokuDB エンジンのサポートを停止しています。 このトピックでは、ストレージエンジンを TokuDB から InnoDB に切り替える方法について説明します。

背景情報

Percona 社が TokuDB のサポートを停止したため、修正されないバグが発生し、極端な場合は業務上の損失が発生する可能性があります。 このため、ApsaraDB RDS MySQL は 2019 年 8 月 1 日から、TokuDB エンジンのサポートを停止しています。 エンジンを直接変更すると、DML 操作がブロックされるため、同時実行性に影響があります。 そのため、できるだけ早く業務を評価し、後述するソリューションのいずれかによるストレージエンジンの切り替えを推奨します。

TokuDB のサポート停止日

2019 年 8 月 1 日

影響範囲

TokuDB ストレージエンジンを使用するインスタンス

show engines; コマンドを使用して、インスタンスの現在のデフォルトエンジンを表示するか、または Show create table <table name>; コマンドを使用してテーブルのストレージエンジンを表示します。

注意事項

  • ストレージエンジンを変更すると、スペースの使用量が増加します。 必要となるスペースは、並列操作中の TokuDB テーブルの容量の約 2 倍です。 操作中のスペース使用量に注意してください。
  • ストレージエンジンの変更後、CPU 使用率は減少しますが、同じデータ量を読み取る場合の IOPS は増加します。 これは、データページが圧縮されていないためです。
  • データベース全体の移行中に、エンドポイントを切り替える必要があります。 エンドポイントの切り替えは、オフピーク時に実行することを推奨します。
  • データベース全体移行中にデータベースのバージョンが変更される場合は、事前の互換性確認を推奨します。

推奨されるソリューション

  • インスタンスのテーブルサイズが 100 MB 未満で、短期間のブロッキングが許容される場合、ソリューション 1 を使用して短時間テーブルをロックすることで、さまざまなツールの設定プロセスを回避できます。
  • インスタンスのテーブルサイズが 5 GB を超える場合、ソリューション 2 または 3 の使用を推奨します。
  • インスタンス内のすべてのテーブルを InnoDB エンジンに移行する必要がある場合、ソリューション 3 または 4 の使用を推奨します。
  • すべてのテーブルを InnoDB エンジンに移行後、 default_storage_engine パラメーターを InnoDB に設定します。

ソリューション 1

このソリューションは、最も簡単な方法でテーブルを InnoDB に移行します。 ただし、プロセス全体で DML 操作がブロックされる場合があり、大きなテーブルの移行には長い時間が必要となります。

手順

  1. DMS を使用した RDS インスタンスへのログイン.
  2. 上部のナビゲーションバーで [SQL 操作] > [SQLウィンドウ] を選択します。
  3. 以下のコマンドを実行します。
    Alter table test.testfs engine innodb
    直接変更

ソリューション 2

このソリューションでは、サードパーティ製のツールを使用してテーブルを移行します。 Percona 社製のpt-oscや、Github で開発されたgh-ostなどのサードパーティー製ツールがオンライン DDL をサポートしています。この例では、gh-ost を使用して移行プロセスを説明します。 詳細は、gh-ostをご参照ください。

原理

gh-ost は、元のテーブルと同じスキーマを持つ一時テーブルを作成し、元のテーブルから一時テーブルにデータを増分コピーします。 すべてのデータが一時テーブルにコピーされると、gh-ost は疑似スレーブプロセスからバイナリログを読み取り、元のテーブルから一時テーブルにテーブルの変更をリアルタイムで同期します。 最後に、オフピーク時にテーブルの名前を変更して移行を完了します。 このソリューションでは、最初の全体データの同期中、入出力の負荷が大きくなります。 ただし、パラメータを変更して入出力を制限できます。
  • 利点:gh-ost を使用すると、同期プロセスをより詳細に制御できます。
  • 欠点:コマンドを使用して各テーブルを同期する必要があります。 多数のテーブルが存在する場合、操作は面倒です。

パラメーター

パラメーター 説明 
--initially-drop-old-table 既存のテーブルをチェックして削除します。
--initially-drop-ghost-table 既存の ghost テーブルをチェックして削除します。
--aliyun-rds ApsaraDB for RDS でテーブルの移行を実行します。
--assume-rbr RBR (行ベースレプリケーション) 形式のバイナリログを読み取るように gh-ost を設定します。
--allow-on-master プライマリデータベースで gh-ost を実行します。
--assume-master-host プライマリデータベースのエンドポイントを設定します。
--user データベースアカウントの名前を設定します。
--password データベースのパスワードを設定します。
--host データベースのエンドポイントを設定します。プライマリデータベースのエンドポイントと同じである必要があります。
--database データベース名を設定します。
--table ghost テーブルの名前を設定します。
--alter ghost テーブルを変更します。
--chunk-size 一括送信する行数を設定します。
--postpone-cut-over-flag-file 移行完了プロセスの延期に使用するファイルを指定します。 このファイルを削除すると、テーブルは直ちに切り替えられます。
--panic-flag-file ghost プロセスの停止に使用するファイルを指定します。 このファイルが生成されると、ghost プロセスは直ちに停止します。
--serve-socket-file 対話型コマンドを受け取ります。
--execute テーブルの移行と切り替えを直接実行します。

前提条件

  • gh-ostは、ローカルホストまたはECSインスタンスにインストールされます。
  • ローカルホストまたは ECS インスタンスの IP アドレスが、ApsaraDB for RDS インスタンスの IP アドレスホワイトリストに追加されます。

手順

  1. ローカルホストまたは ECS インスタンスで次のコマンドを実行して移行処理を実行し、移行完了まで待ちます。
    gh-ost --user="test01" --password="Test123456" --host="rm-bpxxxxx.mysql.rds.aliyuncs.com"  --database="test" --table="testfs"  --alter="engine=innodb" --initially-drop-old-table --initially-drop-ghost-table --aliyun-rds --assume-rbr --allow-on-master --assume-master-host="rm-bpxxxxx.mysql.rds.aliyuncs.com" --chunk-size=500 --postpone-cut-over-flag-file="/tmp/ghostpost.postpone" --panic-flag-file="/tmp/stop.flag" --serve-socket-file="/tmp/ghost.sock" --execute
  2. DMS を使用した RDS インスタンスへのログイン.
  3. 左側に、"_gho" および "_ghc" で終わる一時テーブルが表示されます。一時テーブルの作成
  4. コマンド rm/tmp/ghostpost.postpone を実行して、テーブルの切り替えを開始します。 結果は以下のとおりです。テーブルの切り替え開始
    表示されたエラーは無視して構いません。 移行は完了しています。
  5. テーブルおよびデータを確認します。
    データが正しいことを確認してから、"_del" テーブルを削除します。
    移行が完了しました。

ソリューション 3

このソリューションでは、Alibaba Cloud DTS (Data Transmission Service) を使用して、元のテーブルのデータをリアルタイムで一時テーブルに同期し、オフピーク時に元のテーブルをロックし、テーブルの名前を変更します。 このソリューションでは、多数のテーブルを同時に移行できます。

手順

  1. DMS を使用した RDS インスタンスへのログイン.
  2. 上部のナビゲーションバーで、 [SQL 操作] > [SQL ウィンドウ] を選択します。
  3. Run the following command to create a temporary table:
    CREATE TABLE `testfs_tmp` (
      `id` int(11) NOT NULL AUTO_INCREMENT,
      `vc` varchar(8000) DEFAULT NULL,
      PRIMARY KEY (`id`)
    ) ENGINE=innodb  DEFAULT CHARSET=utf8
    					
  4. します。DTS インスタンスを購入します。
    DTS インスタンスは課金対象です。 詳細については、データ送信サービスの価格 をご参照ください。
  5. DTS コンソール左側のナビゲーションペインで [データ同期] をクリックします。
  6. 購入した DTS インスタンスの [アクション] 列で、 [同期チャネルの設定] をクリックします。
  7. 以下のパラメーターを設定します。
    カテゴリー パラメーター 説明 
    ソースインスタンスの詳細 インスタンスタイプ [RDS インスタンス] を選択します。
    インスタンス ID ストレージエンジンを切り替える RDS インスタンスを選択します。
    暗号化 [暗号化なし] または [SSL 暗号化] を選択します。 [SSL 暗号化] を選択するには、 SSL 暗号化を有効化しておく必要があります。 SSL 暗号化を有効にすると、CPU 消費量が大幅に増加します。
    ターゲットインスタンスの詳細 インスタンスタイプ [RDS インスタンス] を選択します。
    インスタンス ID ストレージエンジンを切り替えるRDSインスタンスを選択します。
    暗号化 [暗号化なし] または [SSL 暗号化] を選択します。 [SSL 暗号化] を選択するには、 SSL 暗号化を有効化しておく必要があります。 SSL 暗号化を有効にすると、CPU 消費量が大幅に増加します。
  8. [ホワイトリストを設定して次のステップに進む] をクリックします。
  9. 同期アカウントが作成されるまで待ちます。 [次へ] をクリックします。
  10. 左側の testfs テーブルを右に移動し、 [編集] をクリックします。
  11. [テーブル名] testfs_tmp に設定し、 [OK] をクリックします。
  12. [次へ] をクリックします。
  13. [初回の全データ同期] を選択し、 [事前確認] をクリックします。
  14. 事前チェックが完了するまで待ち、 [閉じる] をクリックします。
  15. データ同期の待機時間は 0 ミリ秒です。
  16. DMS の SQL ウィンドウで、テーブル名を変更するコマンドを実行します。
    テーブル名を "testfs" から "testfs_del" に、 "testfs_tmp" を "testfs" に変更します。
    • 移行完了後、DTS が同期エラーを報告しますが、無視してかまいません。
    • 追加料金の発生を避けるために、データの確認後、直ちに DTS インスタンスをリリースしてください。

ソリューション 4

このソリューションでは、DTS を使用して、データベースインスタンスのデータを新しいインスタンスに同期します。 このソリューションは、インスタンスのアップグレードが必要なインスタンス、または比較的長いサービス停止時間が許容されるインスタンスに適用されます。

手順

  1. 移行元インスタンスからすべてのスキーマスクリプトをエクスポートし、スクリプト内のエンジン部分を削除または変更します。
    たとえば、 create table t1(id int,name varchar(10)) engine=tokudb; create table t1(id int,name varchar(10)) engine=innodb; に変更します。
  2. RDS インスタンスを作成し、変更されたスクリプトを使用してデータベースとテーブルを作成します。
  3. DTS を使用して、移行元インスタンスから新しいインスタンスにデータを移行します。 詳細については、「」「RDS インスタンス間でリアルタイム同期タスクを作成する」をご参照ください。
    同期の初期化中は、 [初回の全データ同期] のみを選択します。
  4. 同期の遅延がないことを確認後、アプリケーションの接続アドレスを新しいインスタンスのエンドポイントに切り替えます。