2019年8月1日以降、ApsaraDB RDS for MySQLはTokuDBエンジンをサポートしなくなりました。 このトピックでは、ストレージエンジンをTokuDBからInnoDBに変更する方法について説明します。
背景情報
PerconaはTokuDBのサポートを提供しなくなり、既知のバグを修正できず、極端な場合にビジネスの損失が発生します。 その結果、ApsaraDB RDS for MySQLはTokuDBエンジンのサポートを2019年8月1日から終了しました。 ストレージエンジンを直接変更すると、DML操作がブロックされ、同時実行が影響を受ける可能性があります。 できるだけ早い機会にワークロードを評価し、次のいずれかのソリューションを使用してストレージエンジンを変更することをお勧めします。
有効日
August 01, 2019
適用範囲
TokuDBストレージエンジンを使用するRDSインスタンス
RDSインスタンスの現在のデフォルトエンジンを表示するにはSHOW ENGINES; ステートメントを実行し、テーブルのストレージエンジンを表示するにはSHOW CREATE TABLE <table name>; ステートメントを実行します。
使用上の注意
ストレージエンジンが変更されると、ストレージ使用量が増加します。 エンジン交換操作のために確保する必要があるストレージ容量は、並列操作中のTokuDBテーブルのストレージの約2倍です。 操作中のストレージ使用量に注意してください。
ストレージエンジンが変更されると、CPU使用率は低下しますが、同じ量のデータを読み取るとIOPSは増加します。 これは、データページが圧縮されていないためです。
完全移行中、エンドポイントは切り替えられます。 オフピーク時に移行を実行することを推奨します。
完全移行中にデータベースエンジンのバージョンが変更された場合は、事前に互換性をテストすることをお勧めします。
推奨されるソリューション
RDSインスタンスのテーブルサイズが100 MB未満で、短期ブロックが許容される場合は、ソリューション1を使用できます。 このソリューションは、短時間テーブルをロックし、さまざまなツールの設定から解放されます。
RDSインスタンスのテーブルサイズが5 GBを超える場合は、ソリューション2または3を使用することを推奨します。
RDSインスタンスのすべてのテーブルのストレージエンジンをInnoDBエンジンに変更する必要がある場合は、ソリューション3または4を使用することを推奨します。
ストレージエンジンを変更した後、default_storage_engineパラメーターの値をInnoDBに変更する必要があります。
ソリューション 1
このソリューションは、ストレージエンジンを直接変更します。 ただし、DML操作はプロセス全体でブロックされる可能性があり、大きなテーブルを移行するには長い時間が必要です。
DMSからRDS MySQLインスタンスにログイン データ管理 (DMS) を使用してRDSインスタンスにログインします。
上部のナビゲーションバーで、を選択します。
実行するステートメントは、次のとおりです。
の変更テーブルtest.testfs engine innodb
ソリューション 2
このソリューションでは、サードパーティ製のツールを使用してテーブルを移行します。 Perconaによって開発されたpt-oscやGitHubによって開発されたgh-ostなど、さまざまなサードパーティツールがオンラインDDL操作をサポートしています。 この例では、gh-ostを使用して移行プロセスを説明します。 詳細は、 gh-ost をご参照ください。
原理
テーブルを移行するために、gh-ostは元のテーブルと同じスキーマを持つ一時テーブルを作成し、元のテーブルから一時テーブルにデータを増分コピーします。 すべてのデータが一時テーブルにコピーされた後、gh-ostはシミュレートされたスレーブプロセスを使用してバイナリログを読み取り、元のテーブルから一時テーブルへのテーブル変更をリアルタイムで同期します。 次に、gh-ostはテーブルの名前を変更して、オフピーク時間中に移行を完了します。 このソリューションは、初期フルデータ同期中のI/Oパフォーマンスに影響します。 ただし、パラメータを変更して入出力を制限できます。
利点: gh-ostを使用すると、データ移行の時点を指定し、同期プロセスを制御できます。
デメリット: コマンドを使用して各テーブルを同期する必要があります。 多数のテーブルが存在する場合、操作は面倒です。
パラメーター
パラメーター | 説明 |
--initially-drop-old-table | 既存のテーブルをチェックして削除します。 |
--initially-drop-ghost-table | 既存の ghost テーブルをチェックして削除します。 |
--aliyun-rds | ApsaraDB RDSのテーブルを移行します。 |
--assume-rbr | ローベースレプリケーション (RBR) 形式でバイナリログを読み取るようにgh-ostを設定します。 |
--allow-on-master | プライマリデータベースで gh-ost を実行します。 |
--assume-master-host | プライマリデータベースのエンドポイントを設定します。 |
--user | データベースアカウントの名前を設定します。 |
--password | データベースアカウントのパスワードを指定します。 |
--host | データベースのエンドポイントを設定します。プライマリデータベースのエンドポイントと同じである必要があります。 |
--database | データベース名を設定します。 |
--table | テーブルの名前を指定します。 |
--alter | テーブルを変更します。 |
--chunk-size | バッチで送信される行の数を指定します。 |
--postpone-cut-over-flag-file | 移行プロセスを延期するために使用されるファイルを指定します。 指定した時点でファイルを削除すると、テーブルはすぐに移行されます。 |
--panic-flag-file | ゴーストプロセスの停止に使用するファイルを指定します。 このファイルが生成されると、ゴーストプロセスは直ちに停止します。 |
--serve-socket-file | 対話型コマンドを受け取ります。 |
--execute | テーブル移行を直接実行します。 |
前提条件
gh-ostは、オンプレミスホストまたはElastic Compute Service (ECS) インスタンスにインストールされます。
オンプレミスホストまたはECSインスタンスのIPアドレスが、RDSインスタンスのIPアドレスホワイトリストに追加されます。
手順
オンプレミスホストまたはECSインスタンスで次のコマンドを実行して移行を実行し、移行が完了するまで待ちます。
gh-ost-user="test01"-password="Test123456"-ホスト="rm-bpxxxxx.mysql.rds.aliyuncs.com"-データベース="テスト"-テーブル="testfs"-alter="engine=innodb"-初期ドロップ-古い-テーブル-初期ドロップ-ゴースト-テーブル-初期ドロップ-ゴースト-テーブル-aliyun-rds-assume-rbr-allow-on-master rm-bpxxxxx.mysql.rds.aliyuncs.com "-- chunk-size=500 -- deposit-cut-over-flag-file="/tmp/ghostpost. expose "-- panic-flag-file="/tmp/stop.flag "-- serve-socket-file="/tmp/ghost.sock "-- execute
DMSからRDS MySQLインスタンスにログイン DMSを使用してRDSインスタンスにログインします。
左側のナビゲーションウィンドウで、テーブルを確認します。 _ghoと_ghcで終わる一時テーブルが表示されます。
rm /tmp/ghostpost. exposeコマンドを実行して、テーブルの移行を開始します。 次の図は、サンプル出力を示しています。
説明出力に表示されたエラーは無視できます。 移行が完了しました。
テーブルおよびデータを確認します。
説明データが正しいことを確認し、_delテーブルを削除します。
ソリューション 3
このソリューションでは、Alibaba Cloud DTS (Data Transmission Service) を使用して、元のテーブルのデータをリアルタイムで一時テーブルに同期し、オフピーク時に元のテーブルをロックし、テーブルの名前を変更します。 このソリューションを使用すると、多数のテーブルを同時に移行できます。
上部のナビゲーションバーで、を選択します。
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, 主要なキー ('id') ) エンジン=innodb DEFAULT CHARSET=utf8- 説明
データ同期インスタンスに対して課金されます。 詳細については、以下をご参照ください。 データ伝送サービスの価格。
DTS コンソール左側のナビゲーションペインで [データ同期] をクリックします。
購入したデータ同期インスタンスを見つけ、[操作] 列の [同期チャネルの設定] をクリックします。
パラメーターを設定します。 下表に、各パラメーターを説明します。
セクション
パラメーター
説明
ソースインスタンスの詳細
インスタンスタイプ
[RDS インスタンス] を選択します。
Instance ID
ストレージエンジンを変更するRDSインスタンスを選択します。
暗号化
[暗号化なし] または[SSL 暗号化] を選択します。 SSL暗号化を選択する場合は、SSL暗号化を有効にする必要があります。 SSL暗号化を有効にすると、CPU使用率が大幅に向上します。 詳細については、以下をご参照ください。 RDSインスタンスのSSL暗号化を設定します。
ターゲットインスタンスの詳細
インスタンスタイプ
[RDS インスタンス] を選択します。
Instance ID
ストレージエンジンを変更するRDSインスタンスを選択します。
暗号化
[暗号化なし] または[SSL 暗号化] を選択します。 SSL暗号化を選択する場合は、SSL暗号化を有効にする必要があります。 SSL暗号化を有効にすると、CPU使用率が大幅に向上します。 詳細については、以下をご参照ください。 RDSインスタンスのSSL暗号化を設定します。
[ホワイトリストを承認して次のステップに進む] をクリックします。
同期アカウントが作成されるまで待ちます。 [次へ] をクリックします。
testfsテーブルを左側のセクションから右側のセクションに移動し、[編集] をクリックします。
データベース名をtestfs_tmpに設定し、[OK] をクリックします。
[次へ] をクリックします。
[初回の全データ同期] を選択し、 [事前確認] をクリックします。
事前チェックが完了するまで待ちます。 次に、[閉じる] をクリックします。
データ同期が完了するまで待ちます。 Delayパラメーターに0ミリ秒が表示されている場合、データの同期は完了です。
DMS の SQL ウィンドウで、テーブル名を変更するコマンドを実行します。
テーブル 'testfs' の名前を 'testfs_del '、'testfs_tmp' の名前を 'testfs' に変更します。説明移行後、DTSは同期エラーを報告しますが、これは無視できます。
追加料金を防ぐため、データの検証後、できるだけ早い機会にデータ同期インスタンスをリリースすることを推奨します。
ソリューション 4
このソリューションでは、DTS を使用して、データベースインスタンスのデータを新しいインスタンスに同期します。 このソリューションは、インスタンスのアップグレードが必要なインスタンス、または比較的長いサービス停止時間が許容されるインスタンスに適用されます。
移行元インスタンスからすべてのスキーマスクリプトをエクスポートし、スクリプト内のエンジン部分を削除または変更します。
説明たとえば、
create table t1(id int,name varchar(10)) engine=tokudb;をcreate table t1(id int,name varchar(10)) engine=innodb;に変更します。RDSインスタンスを作成し、変更したスクリプトを使用してデータベースとテーブルを作成します。 詳細については、「ApsaraDB RDS For MySQLインスタンスの作成」をご参照ください。
DTS を使用して、移行元インスタンスから新しいインスタンスにデータを移行します。 詳細については、以下をご参照ください。 ApsaraDB RDS for MySQLインスタンス間の一方向データ同期の設定
説明同期の初期化中は、 [初回の全データ同期] のみを選択します。
同期レイテンシが発生しないことを確認したら、アプリケーション接続アドレスを新しいインスタンスのエンドポイントに変更します。