ApsaraDB RDS:[提供終了] TokuDB エンジンから InnoDB エンジンへの変換

背景情報

Percona 社は TokuDB のサポートを終了しました。これにより、既知のバグが修正されず、ビジネスに支障をきたす可能性があります。このため、Alibaba Cloud は2019年8月1日に ApsaraDB RDS for MySQL における TokuDB ストレージエンジンのサポートを終了しました。ストレージエンジンを直接変換すると DML 操作がブロックされ、同時実行性に影響を与える可能性があります。ビジネス要件を評価した上で、以下のいずれかのソリューションを選択して変換を実行してください。

TokuDB エンジンの提供終了日

2019年8月1日

適用範囲

TokuDB ストレージエンジンを使用しているインスタンスが対象です。

注意事項

• ストレージエンジンを変換すると、ストレージ使用量が増加します。約 TokuDB テーブルの 2 倍のサイズの空き領域を確保する必要があります。操作中は、ストレージ使用量を注意深く監視してください。

• 変換後、CPU 使用率は低下しますが、IOPS は増加します。これは、データページが圧縮されないため、同量のデータを読み取るためにより多くの I/O 操作が必要になるためです。

• フルマイグレーションを実行する際は、アプリケーションのエンドポイントを切り替える必要があります。ビジネスへの影響を最小限に抑えるため、この操作はピーク時間外に実行することを推奨します。

• フルマイグレーション中にデータベースのバージョンを変更する場合は、事前に互換性テストを実施することを推奨します。

推奨ソリューション

• テーブルが小さい (100 MB 未満) 場合や、アプリケーションが短時間の中断を許容できる場合は、ソリューション1を使用してください。この方法では、テーブルのロック時間が短く、複雑なツールの設定を回避できます。

• テーブルが大きい (5 GB 超) 場合は、ソリューション2またはソリューション3を使用してください。

• インスタンス内のすべてのテーブルを変換する必要がある場合は、ソリューション3またはソリューション4を使用してください。

• エンジンを変換した後、[default_storage_engine] インスタンスパラメーターを [InnoDB] に変更します。

ソリューション1

このソリューションでは、ALTER TABLE 文を使用してエンジンを直接変換します。これは最も簡単な方法ですが、テーブルに対する DML 操作をブロックするため、大きなテーブルの場合は時間がかかる可能性があります。

1. Data Management (DMS) を使用して ApsaraDB RDS データベースにログインします。

2. 上部のナビゲーションバーで、[SQL 操作] > [SQL ウィンドウ] を選択します。

3. 以下のコマンドを実行します。

   ALTER TABLE test.testfs ENGINE=innodb;

   【SQL実行: (1)】
   Alter table test.testfs engine innodb
   実行に成功しました。所要時間: [18185ms]

ソリューション2

このソリューションでは、サードパーティのオンラインスキーマ変更ツールを使用して、ダウンタイムを最小限に抑えて変換を実行します。Percona 社の pt-osc や GitHub の gh-ost など、多くのツールがオンライン DDL をサポートしています。このセクションでは、gh-ost を例として使用します。詳細については、公式の gh-ost ドキュメントをご参照ください。

仕組み

パラメーター

前提条件

• オンプレミスホストまたは Elastic Compute Service (ECS) インスタンスに gh-ost がインストールされていること。

• オンプレミスホストまたは ECS インスタンスの IP アドレスが、ApsaraDB 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

   2019/06/13 17:22:51 binlogsyncer.go:79: [info] create BinlogSyncer with config {999
   2019/06/13 17:22:51 binlogsyncer.go:246: [info] begin to sync binlog from position
   2019/06/13 17:22:51 binlogsyncer.go:139: [info] register slave for master server rm
   2019/06/13 17:22:51 binlogsyncer.go:573: [info] rotate to (mysql-bin.000014, 241268
   # Migrating `test`.`testfs`; Ghost table is `test`.`_testfs_gho`
   # Migrating `xxx`.`xxx`; xxx xxx rds.aliyuncs.com:3306; inspecting xxx
   # Migration started at Thu Jun 13 17:22:50 +0800 2019
   # chunk-size: 500; max-lag-millis: 1500ms; dml-batch-size: 10; max-load: ; critical
   # throttle-additional-flag-file: /tmp/gh-ost.throttle
   # postpone-cut-over-flag-file: /tmp/ghostpost.postpone [set]
   # panic-flag-file: /tmp/stop.flag
   # Serving on unix socket: /tmp/ghost.sock
   Copy: 0/100000 0.0%; Applied: 0; Backlog: 0/1000; Time: 0s(total), 0s(copy); stream
   Copy: 0/100000 0.0%; Applied: 0; Backlog: 0/1000; Time: 1s(total), 1s(copy); stream
   Copy: 1500/100000 1.5%; Applied: 0; Backlog: 0/1000; Time: 2s(total), 2s(copy); str
   Copy: 3000/100000 3.0%; Applied: 0; Backlog: 0/1000; Time: 3s(total), 3s(copy); str
   Copy: 5500/100000 5.5%; Applied: 0; Backlog: 0/1000; Time: 4s(total), 4s(copy); str
   Copy: 7500/100000 7.5%; Applied: 0; Backlog: 0/1000; Time: 5s(total), 5s(copy); str
   Copy: 9000/100000 9.0%; Applied: 0; Backlog: 0/1000; Time: 6s(total), 6s(copy); str
   Copy: 10500/100000 10.5%; Applied: 0; Backlog: 0/1000; Time: 7s(total), 7s(copy); s
   Copy: 13500/100000 13.5%; Applied: 0; Backlog: 0/1000; Time: 8s(total), 8s(copy); s
   Copy: 15500/100000 15.5%; Applied: 0; Backlog: 0/1000; Time: 9s(total), 9s(copy); s
   Copy: 17500/100000 17.5%; Applied: 0; Backlog: 0/1000; Time: 10s(total), 10s(copy);

2. DMS を使用して ApsaraDB RDS データベースにログインします。

3. 左側のメニューでテーブルを表示します。_gho と _ghc で終わる一時テーブルが表示されます。test データベースのテーブルリストに、gh-ost によって作成された一時テーブル _testfs_ghc と _testfs_gho が表示され、変換が進行中であることがわかります。

4. テーブルのカットオーバーを開始するには、 rm /tmp/ghostpost.postpone コマンドを実行します。 以下の出力が表示されます。

   Copy: 100000/100000 100.0%; Applied: 0; Backlog: 0/1000; Time: 9m0s(total), 56s(copy); streamer: mysql-bin.000015:520562237;
   Copy: 100000/100000 100.0%; Applied: 0; Backlog: 0/1000; Time: 9m30s(total), 56s(copy); streamer: mysql-bin.000015:520674422;
   # Migrating `test`.`testfs`; Ghost table is `test`.`_testfs_gho`
   # Migrating xxx xxx xxx mysql.rds.aliyuncs.com:3306; inspecting xxx xxx xxx xxx mysql.rds.aliyuncs.com:3306
   # Migration started at Thu Jun 13 17:22:50 +0800 2019
   # chunk-size: 500; max-lag-millis: 1500ms; dml-batch-size: 10; max-load: ; critical-load: ; nice-ratio: 0.000000
   # throttle-additional-flag-file: /tmp/gh-ost.throttle
   # postpone-cut-over-flag-file: /tmp/ghostpost.postpone
   # panic-flag-file: /tmp/stop.flag
   # Serving on unix socket: /tmp/ghost.sock
   Copy: 100000/100000 100.0%; Applied: 0; Backlog: 0/1000; Time: 9m31s(total), 56s(copy); streamer: mysql-bin.000015:520681377;
   2019/06/13 17:32:23 binlogsyncer.go:107: [info] syncer is closing...
   2019/06/13 17:32:23 binlogstreamer.go:47: [error] close sync with err: sync is been closing...
   2019/06/13 17:32:23 binlogsyncer.go:122: [info] syncer is closed

   説明

   出力のエラーメッセージは無視してかまいません。カットオーバーは完了しています。

5. テーブルスキーマを確認し、データを検証します。

   説明

   データが正しいことを確認した後、gh-ost によって元のテーブルからリネームされた _testfs_del テーブル (命名規則は _<元のテーブル名>_del) を削除できます。

   show create table `testfs`; を実行してテーブルスキーマを表示し、AUTO_INCREMENT の値が 100001 であることを確認してください。これは、すべてのデータが保持されていることを示します。

ソリューション3

このソリューションでは、Alibaba Cloud Data Transmission Service (DTS) を使用して、元のテーブルから InnoDB エンジンを使用する一時テーブルにデータを同期します。その後、ピーク時間外にテーブル名の変更を実行します。このソリューションは、多数のテーブルを同時に変換する場合に適しています。

1. DMS を使用して ApsaraDB RDS データベースにログインします。

2. 上部のナビゲーションバーで、[SQL 操作] > [SQL ウィンドウ]を選択します。

3. 次のコマンドを実行して、InnoDB エンジンを使用する一時テーブルを作成します：

   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. データ同期インスタンスを購入しますデータ同期インスタンスを購入します。

   説明

   データ同期インスタンスは有料サービスです。詳細については、「Data Transmission Service の料金」をご参照ください。

5. DTS コンソールの左側のメニューで、データ同期 をクリックします。

6. 購入したデータ同期インスタンスを見つけ、[操作] 列で [同期チャネルの設定] をクリックします。

7. ソースインスタンスとターゲットインスタンスを設定します。

   セクション	パラメーター	説明
   ソースインスタンスの詳細	インスタンスタイプ	RDS インスタンス を選択します。
   	インスタンスID	変換したい TokuDB テーブルが含まれる RDS インスタンスを選択します。
   	暗号化	[非暗号化] または SSL セキュア接続 を選択します。SSL セキュア接続 を選択した場合は、まず SSL 暗号化を有効にする必要があります。このオプションは CPU 使用率を大幅に増加させます。
   ターゲットインスタンスの詳細	インスタンスタイプ	RDS インスタンス を選択します。
   	インスタンスID	変換したい TokuDB テーブルが含まれる RDS インスタンスを選択します。
   	暗号化	[非暗号化] または SSL セキュア接続 を選択します。SSL セキュア接続 を選択した場合は、まず SSL 暗号化を有効にする必要があります。このオプションは CPU 使用率を大幅に増加させます。

   このページには、[同期ジョブ名] フィールドと [インスタンスリージョン] ドロップダウンリスト (例：中国 (杭州)) も含まれています。設定後、[ホワイトリストを設定して次へ] をクリックします。

8. [ホワイトリストを設定して次へ] をクリックします。

9. 同期アカウントが作成されるのを待ち、次へ をクリックします。

10. 同期オブジェクトを設定します：[同期タイプ] を [一方向同期 (DML+DDL)] に設定し、[既存のターゲットテーブルの処理モード] を [事前チェックとエラー報告] に設定します。左側の [ソースオブジェクト] ペインで、test002 データベースの testfs テーブルを選択し、右側の [選択したオブジェクト] ペインに移動して、オブジェクトにカーソルを合わせて 編集 をクリックします。

11. データベース名 を、以前に作成した testfs_tmp に変更し、OK をクリックします。

12. 次へ をクリックします。

13. [初期フルデータ同期] のみを選択し ([スキーマ移行] は選択せずに)、事前チェックして開始する をクリックします。

14. 事前チェックが完了するのを待ち、閉じる をクリックします。

15. データ同期のレイテンシーが 0 ms になるまで待ちます。同期タスクのステータスが [同期中] に変わり、データ同期が開始されたことを示します。

16. DMS SQL ウィンドウで、テーブル名を切り替えるには、以下のコマンドを実行します。

    RENAME TABLE `testfs` TO `testfs_del`, `testfs_tmp` TO `testfs`;

    説明

    • テーブルが切り替えられた後、DTS タスクはエラーを報告します。これは想定される動作です。

    • データを検証した後、追加料金が発生しないよう、できるだけ早くデータ同期インスタンスをリリースしてください。

ソリューション4

このソリューションでは、DTS を使用してデータベースのフルマイグレーションを新しいインスタンスに実行します。このアプローチは、インスタンスのアップグレードも計画している場合や、アプリケーションがカットオーバーのためのより長いダウンタイムを許容できる場合に適しています。

1. ソースインスタンスからスキーマを CREATE TABLE 文としてエクスポートします。スクリプトで、各テーブルの ENGINE 句を変更します。

   説明

   たとえば、create table t1(id int,name varchar(10)) engine=tokudb; を create table t1(id int,name varchar(10)) engine=innodb; に変更します。

2. ApsaraDB RDS for MySQL インスタンスを作成し、変更したスクリプトを実行して InnoDB エンジンでデータベースとテーブルを作成します。

3. DTS を使用して、ソースインスタンスから新しいインスタンスにデータを同期しますソースインスタンスから新しいインスタンスにデータを同期します。

   説明

   DTS タスクを設定する際は、[初期フルデータ同期] のみを選択してください。

4. 同期レイテンシーがゼロであることを確認した後、アプリケーションのエンドポイントを新しいインスタンスに切り替えます。