MySQLまたはMariaDBデータベースプラットフォームを使用している大規模な組織は、ある場所から別の場所へのデータベース移行を実行する必要に直面することがよくあります。プラットフォームに関係なく、データベースソフトウェアの種類（RDBMSからNoSQLへの移行やNoSQLからRDBMSへの移行など）、または単なるデータ移行の場合、移行の実行には膨大な作業とコストがかかります。
データベースの移行には、常に1つ以上のソースデータベースから1つ以上のターゲットデータベースにデータを移行するプロセスが含まれます。これには、データベース移行サービス、またはエンジニアがサービスを作成してこの種の問題に合わせて調整するために構築したツールのマッシュアップセットが含まれる場合があります。
データベースの移行は、ソースデータベースプラットフォームがターゲットプラットフォームを元のソースとまったく同じになることを意味するものではないと予想されます。移行が完了すると、ターゲットデータベースのデータセットが再構築される可能性があります。移行が完全に完了すると、最も重要なことは、データベースにアクセスするクライアントが新しいソースデータベースにリダイレクトされることです。新しいソースデータベースは、ソースからのデータの正確なコピーを提供する必要があり、全体的なユーザーエクスペリエンスに影響を与える可能性のあるパフォーマンスへの影響はありません。
あるプラットフォームからターゲットの宛先プラットフォームにデータを移動することは、非常に大きな作業です。これは、組織または企業がさまざまな理由で現在のプラットフォームへのライトをオフにすることを決定した場合に、データベースの移行がカバーするものです。データを移行する一般的な理由は、ターゲットの移行先プラットフォームへの費用対効果、または展開時の柔軟性とスケーラビリティのためです。現在の本番データをホストしている現在のプラットフォームでは、アップグレードとスケーラビリティの面でより多くのコストが発生しますが、マイクロサービスプラットフォームに実際にデプロイできる小さな変更をデプロイする場合は、負担が大きくなります。
このブログでは、より均質なデータベース移行でのMySQLおよびMariaDBの移行に使用できるトップのオープンソースツールに焦点を当てます。
移行を実行するときに使用する最も簡単なパスは、データベースバックアップツールを使用することです。これらのツールとは何か、移行中にどのように使用できるかを見ていきます。
mysqldump / mysqlpump
このツールは、データベース管理者またはシステム管理者がこのツールをフックしてデータベース全体またはデータベースの部分コピーを移行する、MySQLまたはMariaDBの最も有名なユーティリティの1つです。 MySQL / MariaDBに精通していないデータベース管理者の場合、このツールを使用すると、バックアップのコピーを作成して、ターゲットデータベースにダンプできるデータの論理コピーを生成できます。
このツールを使用する場合の一般的な設定は、ターゲットデータベースが別の場所にあり、ソースとは異なるプラットフォームでホストされている場合、ターゲットはスレーブまたはレプリカとして機能します。ビジー状態のシステムで--single-transactionを使用して一般的に呼び出されるmysqldumpを使用し、-master-dataを使用すると、データ移行のホストとして使用されるターゲットデータベースにスレーブを設定するための座標が提供されます。 mysqldumpの代わりにmysqlpumpもありますが、機能は劣りますが、データベースとデータベース内のオブジェクトの並列処理を実行して、ダンププロセスを高速化できます。欠点は、mysqlpumpでは、データベース移行のターゲット宛先として使用されるレプリカを作成する場合に非常に役立つ--master-dataなどのオプションが使用できないことです。
mysqlpumpは、データがアイドル状態であるか、ソースデータベースへの書き込みや変更が処理されないようにメンテナンスモードになっている場合に有利です。 mysqldumpと比較して高速です。
mydumper / myloader
mydumper / myloaderは非常に便利で効率的なツールであり、並列処理、チャンクによるデータ送信機能、しきい値と制御のサポートを提供するため、特に処理速度の速いバルクデータのインポートに論理バックアップに使用できます。スレッド数、行数、ステートメントサイズを評価し、結果を圧縮します。バイナリログファイルとログ位置が生成または含まれます。これは、現在のソースおよび本番環境のレプリカとして機能するようにターゲットの宛先プラットフォームを設定する場合に非常に役立ちます。
基本的に、mydumperはバイナリであり、論理バックアップを作成するためにコマンドラインから呼び出す必要のあるコマンドです。一方、myloaderはバイナリであり、目的のターゲット宛先にデータをロードするときに使用する必要のあるコマンドです。その柔軟性により、バックアップの作成またはデータのロードに関係なく、アクションを処理するときに必要なレートを管理できます。 mydumperを使用して、ソースデータベースの完全バックアップまたは部分バックアップコピーを作成することもできます。これは、現在のデータベースホストから移動したい大きなデータまたはスキーマが必要な場合に非常に役立ち、新しいデータベースシャードのセットアップを開始するときに、それを別のターゲットの宛先にわずかに移動します。これは、データセットの巨大なセグメントをプルしてから移動することで、大きなデータを移行する1つの方法でもありますが、新しいシャードノードとして使用できます。
mydumper/myloaderにも制限があります。元の作成者からの更新は停止されていますが、Max Bubeによって保存されていますが、このツールは実稼働環境でも広く使用されています。
Percona XtraBackup / MariaDB Backup
PerconaのXtraBackupは、エンタープライズOracle MySQLEnterpriseBackupを使用したりお金をかけたりしたくないデータベース管理者への贈り物です。 MariaDBBackupはPerconaXtraBackupから分岐して派生していますが、MariaDBEnterpriseBackupもあります。
これらのツールはどちらも、バックアップを実行または取得するときに同じ概念を共有します。これは、ホットオンラインバックアップ、PITR、増分および完全バックアップ、部分バックアップを提供するバイナリバックアップであり、バイナリログファイルと位置を生成するなどのリカバリを理解し、GTIDをサポートするため、データリカバリにも役立ちます。 MariaDBBackupとPerconaXtraBackupは、バックアップの提供に重点を置いたデータベースをサポートするように設計されているため、現在は2つの異なるタイプのソフトウェアです。 MariaDBバックアップは、MariaDBデータベースソースを使用またはバックアップする場合に確実に適用できます。一方、Percona XtraBackupは、Oracle MySQLだけでなく、Percona Server、またはPerconaXtraDBServerやCodershipバージョンのGaleraClusterforMySQLなどの派生MySQLサーバーにも適用できます。
どちらのバックアップも、データベースの移行に非常に役立ちます。ホットオンラインバックアップの実行はより速く、より速く、ターゲットデータベースにロードするために直接使用できるバックアップを生成します。多くの場合、ストリーミングバックアップは、オンラインバックアップを実行し、socatまたはnetcatを使用してバイナリデータをターゲットデータベースにストリーミングできるのと同様に便利です。これにより、ターゲットの宛先へのデータの移動が直接ストリーミングされるため、移行の時間を短縮できます。
このツールを使用する際のデータ移行の最も一般的なアプローチは、ソースからデータをコピーしてから、ターゲットの宛先にデータをストリーミングすることです。ターゲットデータベースの宛先に到達したら、-prepareオプションを使用してバイナリバックアップを準備できます。このオプションでは、バックアップの作成時に記録されたログが適用されるため、完全なデータがそのまま、正確にその時点からコピーされます。バックアップが取られた場所。次に、ターゲットデータベースの宛先をレプリカとして設定して、既存のソースクラスターのレプリカまたはスレーブとして機能し、メインクラスターから発生したすべての変更とトランザクションを複製します。
もちろん、このツールの使用にも制限がありますが、データベース管理者は、このツールの使用方法と、目的の用途に応じて使用を抑制およびカスタマイズする方法を知っている必要があります。ソースがその時点から大量のトラフィックまたは大量の処理を使用している場合は、ソースデータベースを停止したくない場合があります。また、その制限により、PerconaXtraBackupとMariaDBBackupはLinux環境でのみ動作するため、ターゲットソースがLinux互換システムであり、Windowsタイプの環境ではない同種のセットアップが保証されます。
データベースの移行は、特定のツールと特定のタスクについてのみ語るわけではなく、移行が発生する可能性があります。データベースの完全な移行を実行するには、多くの考慮事項と、実行する必要のある後続のタスクがあります。これらの1つは、スキーマの移行またはデータベースの移行です。 MySQL / MariaDBのスキーマは、列と行、イベント、トリガー、ストアドプロシージャまたはルーチン、および関数を含むテーブルのグループで構成されるデータのコレクションです。スキーマのみ、またはテーブルのみを移行したい場合があります。スキーマ上の特定のテーブルでテーブル構造を変更する必要があり、それにDDLステートメントが必要であるとします。問題は、ALTER TABLE ... ENGINE =InnoDBなどの直接DDLステートメントを実行すると、ターゲットテーブルを参照または使用する着信トランザクションまたは接続がブロックされることです。長いデータ定義とテーブルの構造で構成される一部の巨大なテーブルの場合、より現実的な課題が追加され、特にテーブルがホットテーブルの場合はさらに複雑になります。一方、データベースの移行では、ソースからのダウンタイムなしに、テーブル全体の正確な完全コピーをコピーするのは難しい場合があります。では、これらが何であるかを見てみましょう。
pt-online-schema-change
これは、元々MaatkitとAspersaから派生した有名なPerconaToolkitの一部です。このツールは、特に大量のデータで構成されるホットテーブルの場合に、テーブル定義の変更を実行するときに非常に役立ちます。テーブル定義の変更を実行するための一般的でありながら単純なアプローチの場合、ALTERTABLEを実行するとその役割を果たします。ケースはそれで十分ですが、ALGORITHM =INPLACEを使用しないALTERTABLEは、完全なメタデータロックを取得する完全なテーブルコピーを引き起こします。つまり、データベースが長期間積み重なってロックアップする可能性があります。巨大。その場合、このツールはその問題を解決するために構築されています。このツールは、すでに設定されているターゲットデータベースの宛先からの非常に大量のデータを含むホットテーブルの一貫性のないコピーが検出されるという点で、データベースの移行に非常に役立ちます。論理コピーまたはバイナリ/物理コピーを使用してバックアップを実行する代わりに、pt-online-schema-changeを使用して、行をソーステーブルからターゲットテーブルにチャンクごとにコピーできます。要件に応じて、パラメータを適切に呼び出してコマンドをカスタマイズすることもできます。
pt-online-schema-changeを使用する以外に、トリガーも使用します。トリガーを使用することにより、その参照テーブルに変更を適用しようとする後続または進行中のトラフィックも、現在のソースデータベースクラスターのレプリカとして機能するターゲットデータベースにコピーされます。これにより、すべてのデータが、ソースデータベースにあるデータを、たとえば別のプラットフォーム上にあるターゲットデータベースに正確にコピーされます。トリガーの使用は、エンジンがInnoDBであり、そのテーブルに主キーが存在する限り、MySQLとMariaDBに使用できます。これは要件です。 InnoDBが行ロックメカニズムを使用していることをご存知かもしれません。これにより、いくつかのチャンク（選択レコードのグループ）に対して、pt-online-schema-changeがそれをコピーしようとし、INSERTステートメントをターゲットテーブルに適用します。 。ターゲットテーブルは、既存のソーステーブルのまもなく置き換えられるターゲットコピーとして機能するダミーテーブルです。ただし、pt-online-schema-changeを使用すると、ユーザーはダミーテーブルを削除するか、管理者がそのテーブルを削除する準備ができるまでダミーテーブルを配置することができます。テーブルを削除または削除すると、メタデータロックが取得されることに注意してください。トリガーを取得するため、その後の変更はターゲットテーブルに正確にコピーされ、ターゲットテーブルまたはダミーテーブルに不一致が生じることはありません。
gh-ost
pt-online-schema-changeと同じ概念を共有しています。このツールは、pt-online-schema-changeとは異なるアプローチを取ります。このスキーマツールの移行は、データベースの速度が低下し、場合によってはデータベースクラスターがメンテナンスモードでダウンしたり、問題が発生するまで不明な期間ダウンしたりする可能性のある本番ベースの障害に近づきます。解決しました。この問題は通常、トリガーで発生します。スキーマの変更またはテーブル定義の変更が行われているビジーテーブルまたはホットテーブルがある場合、トリガーにより、ロックの競合が原因でデータベースが積み重なる可能性があります。 MySQL / MariaDBトリガーを使用すると、データベースでINSERT、UPDATE、およびDELETEのトリガーを定義できます。ターゲットテーブルがホットスポットにある場合、それは厄介になる可能性があります。着信クエリを強制終了するか、トリガーを削除するのが最善でない限り、データベースはスタックするまで遅くなり始めますが、それが理想的なアプローチではありません。
これらの問題のため、gh-ostはその問題に対処します。これは、特にRBR（Row Based Replication）を使用して、着信イベントまたはトランザクションがバイナリログ形式でログに記録されるバイナリログサーバーがあるかのように機能します。実際、それは非常に安全であり、あなたが直面する必要のある影響に関して心配が少ないです。実際、テストまたはドライラン（pt-online-schema-changeの場合と同じ）を実行するオプションもありますが、レプリカまたはスレーブノードで直接テストします。これは、移行中にターゲットデータベースへの正確なコピーを試して確認する場合に最適です。
このツールは、ニーズに応じて非常に柔軟性があり、クラスターがスタックしたり、悪化した場合にフェイルオーバーやデータリカバリを実行したりしないことを保証します。詳細とこのツールについて知りたい場合は、ShlomiNoachによるGithubからのこの投稿を読むことをお勧めします。
これらの2つのツールは、より推奨されるアプローチですが、他の方法も試すことができます。ほとんどの場合、これらのツールはMySQL / MariaDBトリガーを適用するため、pt-online-schema-changeと同じ概念を共有しています。次のリストは次のとおりです。
- LHM-Railsスタイルのデータベース移行は、アジャイルな方法でデータスキーマを進化させるための便利な方法です。ほとんどのRailsプロジェクトはこのように開始され、最初は変更をすばやく簡単に行うことができます。
- OnlineSchemaChange-Facebookによって作成および開始されました。このツールは、MySQLテーブルのスキーマを非ブロッキング方式で変更するために使用されます
- TableMigrator-深刻なビジネスとTwitterの元従業員によって開始されました。このツールは、MySQLの大きなテーブルのダウンタイムゼロの移行と同じ原則を共有しています。 Railsを使用して実装されているため、Ruby-on-Railsアプリケーション環境がある場合に便利です。
- oak-online-alter-table-これはShlomiNoachによって作成された古いツールですが、pt-online-schema-changeと同じアプローチに何らかの形でアプローチし、非ブロッキングのALTERTABLE操作を実行します。
ある程度有益な、無料で使用できる移行ツールはほとんどありません。移行ウィザードツールを使用することのより利点は、現在の構造を確認したり、移行中にUIが提供する手順に従うだけの便利なGUIを備えていることです。多数のサービスやウィザードツールが存在する可能性がありますが、オープンソースではなく、無料で利用することはできません。もちろん、データベースの移行は非常に複雑ですが体系的なプロセスですが、場合によっては、多大な労力と労力が必要になります。これらの無料ツールを見てみましょう。
MySQL Workbench
名前が示すように、これはMySQL用であり、たとえばPerconaServerなどの派生データベースはデータベースの移行に役立ちます。特に10.2バージョン以降、MariaDBは完全に別のルートに移行しているため、MariaDBのソースまたはターゲットからこれを使用しようとすると、互換性の問題が発生する可能性があります。 Workbenchは、さまざまなソースデータベースからのデータベースなど、異種タイプのデータベースに使用でき、データをMySQLにダンプしたい場合があります。
MySQL Workbenchは、コミュニティバージョンとエンタープライズバージョンで構成されています。それでも、コミュニティバージョンはGPLとして無料で入手できます。GPLはhttps://github.com/mysql/mysql-workbenchにあります。ドキュメントに記載されているように、MySQL Workbenchを使用すると、Microsoft SQL Server、Microsoft Access、Sybase ASE、SQLite、SQL Anywhere、PostreSQL、およびその他のRDBMSテーブル、オブジェクト、データからMySQLに移行できます。移行では、以前のバージョンのMySQLから最新リリースへの移行もサポートされています。
phpMyAdmin
LAMPスタックを使用してWeb開発者として働いている人にとって、このツールは、データベースタスクを処理するときに彼らのスイスアーミーナイフの1つであることは当然のことです。 phpMyAdminは、PHPで記述された無料のソフトウェアツールであり、Webを介したMySQLの管理を処理することを目的としています。 phpMyAdminは、MySQLおよびMariaDBでの幅広い操作をサポートしています。頻繁に使用される操作（データベース、テーブル、列、リレーション、インデックス、ユーザー、権限などの管理）は、SQLステートメントを直接実行する機能を維持しながら、ユーザーインターフェイスを介して実行できます。
インポートとエクスポートに関しては非常に簡単ですが、重要なのはそれが仕事を成し遂げることです。より大規模で複雑な移行の場合でも、これでは目的のニーズを処理するには不十分な場合があります。
HeidiSQL
HeidiSQLは自由ソフトウェアであり、簡単に習得できるようにすることを目的としています。 「Heidi」を使用すると、MariaDB、MySQL、Microsoft SQL、PostgreSQL、SQLiteのいずれかのデータベースシステムを実行しているコンピューターのデータと構造を表示および編集できます。 2002年にAnsgarによって発明されたHeidiSQLは、MariaDBとMySQLで世界中で最も人気のあるツールに属しています。
移行の目的で、あるサーバー/データベースから別のサーバー/データベースに直接エクスポートできます。また、CSVなどのテキストフィールドを許可するインポート機能があり、テーブルの行をCSV、HTML、XML、SQL、LaTeX、Wikiマークアップ、PHPアレイなどのサポートされているさまざまなファイルタイプにエクスポートすることもできます。データベースサーバーの管理を目的としてデータベースを管理するように構築されていますが、これは単純な移行に使用できます。
Percona Toolkitは、GPLの保証の下でオープンソースソフトウェアとして配布されている注目すべきソフトウェアです。 Percona Toolkitは、Perconaによって内部的に一般的に使用される高度なコマンドラインツールのコレクションですが、特にMySQL/MariaDBサーバーに関連するすべてのデータベース作業にも適用できます。
では、特にMySQL / MariaDBの移行において、データの移行にもどのように、そしてなぜ役立つのでしょうか。ここには、移行時および移行後に使用するのに役立つツールがいくつかあります。
前述のように、データ移行の一般的なアプローチは、ターゲットの移行先サーバーをメインのソースデータベースクラスターのレプリカとして、ただし同種のセットアップにすることです。これは、状況がオンプレミスからパブリッククラウドプロバイダーに移行している場合、そのプラットフォームから選択されたノードをセットアップでき、このノードがメインクラスターからのすべてのトランザクションを複製することを意味します。バックアップツールを使用することで、このタイプの移行セットアップを実現できる場合があります。しかし、それだけではありません。 Percona Toolkitには、たとえば、オンプレミスとターゲットの宛先データベースサーバー間のデータの不整合を特定するのに役立つpt-table-checksum/pt-table-syncツールがあります。 pt-table-checksumを使用すると、すべてのデータベースの一連のチャンクに基づいてチェックサム計算を実行したり、特定のデータベース、特定のテーブル、またはテーブルのレコードの範囲に対して選択的にチェックサムを実行したりできます。 pt-table-syncを使用してデータの同期を実行するため、ターゲットデータベースは、メインのソースクラスターからの正確なデータの新しいコピーで再度更新されます。
一方、pt-upgradeは、バックアップツールからの移行が実行された後に非常に役立ちます。 pt-upgradeを使用すると、このツールを使用して、たとえば低速のクエリログファイルから一連のクエリを実行することにより、分析を実行できます。これらの結果を使用して、ソースデータベースとターゲットデータベースサーバーを比較できます。
特に異種セットアップからのデータベースの移行は、非常に複雑になる可能性があります。しかし、同種の設定では、それは非常に簡単です。適切なツールが装備されている限り、データが大きいか小さいかに関係なく、もちろん、移行が完了し、データの一貫性が保たれていることを確認するための正しい体系的なアプローチ。移行で専門家との協議が必要になる場合もありますが、これらのオープンソースツールを試して、目的のデータベース移行タスクを実行することは、常に素晴らしいスタートです。