データベースの移行は、開始方法、使用するツール、およびデータベースの完全な移行を正常に実行する方法を検討するときに、大きな課題を課す可能性があります。以前、MySQLまたはMariaDBの移行に使用できるトップのオープンソースをリストしました。このブログでは、Microsoft Azure DatabaseforMySQLまたはMariaDBからデータを移行する方法を紹介します。
Microsoft Azureは、AWSとGoogleCloudという他の2つのクラウドテクノロジーの巨人との競争相手として知られています。より多くのMicrosoft製品、特に自社製のMSSQL独自のデータベースを専門としています。しかしそれだけでなく、公に提供するフルマネージドサービスデータベースの1つとしてオープンソースもあります。サポートされているデータベースには、MySQLとMariaDBがあります。
MySQL / MariaDB用のAzureデータベースからの移行は面倒な場合がありますが、現在のクラウドプロバイダーとしてAzureでホストしているアーキテクチャの種類とデータセットの種類によって異なります。適切なツールを使用すれば、それを実現でき、完全な移行を実行できます。
MySQLまたはMariaDBでのデータ移行に使用できるツールに焦点を当てます。このブログでは、RHEL/CentOSを使用して必要なパッケージをインストールしています。これを行う方法について、手順と手順を確認してみましょう。
MySQLまたはMariaDB用のAzureデータベースからの移行
Azureデータベースからオンプレミスサーバーにデータを移行する一般的な方法は、論理コピーを使用してバックアップを取ることです。これは、フルマネージドサービスであるAzure DatabaseforMySQLまたはMariaDBと互換性のあるバックアップユーティリティソリューションを使用して実行できます。フルマネージドデータベースサービスはSSHログインを提供しないため、バックアップの物理コピーはオプションではありません。
Azureから既存のデータベースを移行またはダンプする前に、次の考慮事項に注意する必要があります。
- 論理バックアップ（mysqldump、mysqlpump、mydumper / myloaderなど）と復元を使用することが唯一のオプションです。 Azure Database for MySQLまたはMariaDBは、フルマネージドデータベースサービスであるため、物理ストレージへの物理アクセスをサポートしていません。
- InnoDBおよびメモリストレージエンジンのみをサポートします。代替ストレージエンジンからInnoDBへの移行。 MySQLまたはMariaDB用のAzureDatabaseは、InnoDBストレージエンジンのみをサポートしているため、代替ストレージエンジンをサポートしていません。テーブルが他のストレージエンジンで構成されている場合は、Azure Database for MySQLに移行する前に、テーブルをInnoDBエンジン形式に変換してください。
- たとえば、MyISAMテーブルを使用するWordPressまたはWebAppがある場合は、Azure Database for MySQLに復元する前に、まずInnoDB形式に移行してこれらのテーブルを変換します。 ENGINE =InnoDB句を使用して、新しいテーブルを作成するときに使用するエンジンを設定し、復元する前にデータを互換性のあるテーブルに転送します。
- ソースAzureデータベースが特定のバージョンにある場合、ターゲットのオンプレミスサーバーもソースAzureデータベースと同じバージョンになっています。
したがって、これらの制限があるため、データセットにInnoDBストレージエンジンまたはメモリがある場合は、AzureからのデータがInnoDBストレージエンジンまたはメモリである必要があると想定するだけです。
Azureデータベースから論理バックアップを取得する際のパフォーマンスに関する考慮事項
Azureで論理バックアップを作成する唯一の方法は、mysqldumpまたはmysqlpumpを使用することです。これらのツールを使用してダンプを取得するときのパフォーマンスを最適化するには、大規模なデータベースをダンプするときに次の考慮事項に注意してください。
- データベースをダンプするときは、mysqldumpのexclude-triggersオプションを使用してください。データの復元中にトリガーコマンドが起動しないように、ダンプファイルからトリガーを除外します。
- 単一トランザクションオプションを使用して、トランザクション分離モードをREPEATABLE READに設定し、データをダンプする前にSTARTTRANSACTIONSQLステートメントをサーバーに送信します。 1つのトランザクション内で多くのテーブルをダンプすると、復元中に余分なストレージが消費されます。 LOCK TABLESにより保留中のトランザクションが暗黙的にコミットされるため、single-transactionオプションとlock-tablesオプションは相互に排他的です。大きなテーブルをダンプするには、シングルトランザクションオプションとクイックオプションを組み合わせます。
- データベースをダンプするときは、mysqldumpのorder-by-primaryオプションを使用して、データが主キーの順序でスクリプト化されるようにします。
- データをダンプするときにmysqldumpのdisable-keysオプションを使用して、ロード前に外部キー制約を無効にします。外部キーチェックを無効にすると、パフォーマンスが向上します。制約を有効にし、ロード後にデータを検証して、参照整合性を確保します。
- データベースをダンプするときにmysqlpumpのdefer-table-indexesオプションを使用して、テーブルのデータがロードされた後にインデックスが作成されるようにします。
- mysqlpumpのskip-definerオプションを使用して、ビューおよびストアドプロシージャのcreateステートメントからdefinerおよびSQLSECURITY句を省略します。ダンプファイルをリロードすると、デフォルトのDEFINER値とSQLSECURITY値を使用するオブジェクトが作成されます。
- DBAの役割：制限付き。または、（新しいサーバーの作成中に作成された）管理者ユーザーを使用して、ほとんどのDDLおよびDMLステートメントを実行できます。
- SUPER特権：同様に、SUPER特権は制限されています。
- DEFINER：作成するにはスーパー権限が必要であり、制限されています。バックアップを使用してデータをインポートする場合は、CREATE DEFINERコマンドを手動で削除するか、mysqldumpの実行時に--skip-definerコマンドを使用して削除してください。
- システムデータベース：mysqlシステムデータベースは読み取り専用であり、さまざまなPaaS機能をサポートするために使用されます。 mysqlシステムデータベースに変更を加えることはできません。
- SELECT ... INTO OUTFILE：サービスではサポートされていません。
mysqldumpの使用
mysqldumpの使用は、オンプレミスにあるターゲットデータベースノードにインストールする必要があります。後続のすべてのトランザクションがノードにレプリケートされるように、Azureデータベースノードのレプリカとして準備する必要があります。これを行うには、以下の手順に従います。
mysqldumpをインストールします
-
リポジトリを準備します。
＃MySQLの場合
$ yum install https://dev.mysql.com/get/mysql80-community-release-el7-3.noarch.rpm＃MariaDBの場合
$ curl -sS https://downloads.mariadb.com/MariaDB/mariadb_repo_setup | sudo bash
-
mysql-clientパッケージをインストール
＃MySQLの場合
$ yum install -y mysql-community-client.x86_64＃MariaDBの場合
$ yum install -y MariaDB-client-
mysqldumpを使用して、ターゲットノード内で実行することによりデータダンプを作成します。
$ MYSQL_PWD=<YOUR_MYSQL_PASS> mysqldump -h<YOUR_AZURE_DB_HOSTNAME> -u<YOUR_AZURE_USERNAME> --single-transaction --master-data=2 --extended-insert --order-by-primary --disable-keys --databases maximusdb db2 db3 > backups/dump.sql-
MySQL/MariaDBサーバーをターゲットデータベースノードにインストールします
＃MySQLの場合
$ yum install mysql-community-server.x86_64 mysql-community-client mysql-community-common＃MariaDBの場合
$ yum install MariaDB-server.x86_64-
MySQL / MariaDBサーバーインスタンス（my.cnf、ファイル権限、ディレクトリ）をセットアップし、サーバーを起動します。
＃my.cnfの設定（ClusterControlによるmy.cnfデプロイメントの使用を使用）
[MYSQLD]
user=mysql
basedir=/usr/
datadir=/var/lib/mysql
socket=/var/lib/mysql/mysql.sock
pid_file=/var/lib/mysql/mysql.pid
port=3306
log_error=/var/log/mysql/mysqld.log
log_warnings=2
slow_query_log_file=/var/log/mysql/mysql-slow.log
long_query_time=2
slow_query_log=OFF
log_queries_not_using_indexes=OFF
innodb_buffer_pool_size=2G
innodb_flush_log_at_trx_commit=2
innodb_file_per_table=1
innodb_data_file_path=ibdata1:100M:autoextend
innodb_read_io_threads=4
innodb_write_io_threads=4
innodb_doublewrite=1
innodb_log_file_size=256M
innodb_log_buffer_size=32M
innodb_buffer_pool_instances=1
innodb_log_files_in_group=2
innodb_thread_concurrency=0
innodb_flush_method=O_DIRECT
innodb_rollback_on_timeout=ON
innodb_autoinc_lock_mode=2
innodb_stats_on_metadata=0
default_storage_engine=innodb
server_id=1126
binlog_format=ROW
log_bin=binlog
log_slave_updates=1
relay_log=relay-bin
expire_logs_days=7
read_only=OFF
report_host=192.168.10.226
key_buffer_size=24M
tmp_table_size=64M
max_heap_table_size=64M
max_allowed_packet=512M
skip_name_resolve=true
memlock=0
sysdate_is_now=1
max_connections=500
thread_cache_size=512
query_cache_type=0
query_cache_size=0
table_open_cache=1024
lower_case_table_names=0
performance_schema=OFF
performance-schema-max-mutex-classes=0
performance-schema-max-mutex-instances=0
[MYSQL]
socket=/var/lib/mysql/mysql.sock
[client]
socket=/var/lib/mysql/mysql.sock
[mysqldump]
socket=/var/lib/mysql/mysql.sock
max_allowed_packet=512M##データディレクトリをリセットし、データベースシステムファイルを再インストールします
$ rm -rf /var/lib/mysql/*##ログディレクトリを作成する
$ mkdir /var/log/mysql
$ chown -R mysql.mysql /var/log/mysql##MySQLの場合
$ mysqld --initialize##MariaDBの場合
$ mysql_install_db-
MySQL/MariaDBサーバーを起動します
##MySQLの場合
$ systemctl start mysqld##MariaDBの場合
$ systemctl start mariadb-
Azureデータベースから取得したデータダンプをオンプレミスのターゲットデータベースノードにロードします
$ mysql --show-warnings < backups/dump.sql-
Azureデータベースのソースノードからレプリケーションユーザーを作成します
CREATE USER 'repl_user'@'<your-target-node-ip>' IDENTIFIED BY 'repl_passw0rd';
GRANT REPLICATION CLIENT, REPLICATION SLAVE ON *.* TO [email protected]'<your-target-node-ip>' IDENTIFIED BY 'repl_passw0rd';接続元のクライアントとして、ターゲットノードのIPアドレスのIPアドレスを必ず変更してください。
-
MySQL/MariaDBサーバーをAzureデータベースソースノードのレプリカ/スレーブとして設定します
##まず、CHANGEMASTERコマンドを検索または検索しましょう
$ grep -rn -E -i 'change master to master' backups/dump.sql |head -1
22:-- CHANGE MASTER TO MASTER_LOG_FILE='mysql-bin.000006', MASTER_LOG_POS=2938610;## CHANGE MASTERステートメントを実行しますが、レプリケーションのユーザー/パスワードとホスト名を次のように追加します。
CHANGE MASTER TO MASTER_HOST='<YOUR_AZURE_DB_HOSTNAME>', MASTER_LOG_FILE='mysql-bin.000006', MASTER_LOG_POS=2938610, MASTER_USER='repl_user', MASTER_PASSWORD='repl_passw0rd';
##場合によっては、mysqlスキーマを無視する必要があります。次のステートメントを実行します：
SET GLOBAL replicate_wild_ignore_table='mysql.%';##次にスレーブスレッドを開始します
START SLAVE;##スレーブのステータスを確認してください
SHOW SLAVE STATUS \Gこれで、オンプレミスにあるレプリカのソースとして、MySQL/MariaDBのいずれかでAzureデータベースから最終的に複製できるようになりました。
mydumperの使用
MySQLまたはMariaDB用のAzureデータベースは、実際には、1TBなどの大規模なバックアップにmydumperを特別に使用することが代替オプションになる可能性があることを示唆しています。ソースAzureデータベースノードからデータセットのダンプまたはバックアップコピーを取得するときに、並列処理と速度を提供します。
mydumperのインストールから、宛先のオンプレミスサーバーへのロードまで、以下の手順に従います。
-
バイナリをインストールします。バイナリはここhttps://github.com/maxbube/mydumper/releasesにあります。
$ yum install https://github.com/maxbube/mydumper/releases/download/v0.9.5/mydumper-0.9.5-2.el6.x86_64.rpm-
Azureデータベースのソースノードからバックアップを取ります。たとえば、
[[email protected] mydumper]# MYSQL_PWD=<YOUR_AZURE_DB_PASSWORD> /usr/bin/mydumper --outputdir=. --verbose=3 --host=<YOUR_AZURE_DB_HOSTNAME> -u <YOUR_AZURE_USER>@<YOUR_AZURE_DB_HOSTNAME> --port=3306 --kill-long-queries --chunk-filesize=5120 --build-empty-files --events --routines --triggers --compress --less-locking --success-on-1146 --regex='(maximusdb\.|db1\.|db2\.)'
** Message: Connected to a MySQL server
** Message: Using Percona Backup Locks
** (mydumper:28829): CRITICAL **: Couldn't acquire LOCK BINLOG FOR BACKUP, snapshots will not be consistent: You have an error in your SQL syntax; check the manual that corresponds to your MariaDB server version for the right syntax to use near 'BINLOG FOR BACKUP' at line 1
** Message: Started dump at: 2020-10-26 01:34:05
** Message: Written master status
** Message: Multisource slave detected.
** Message: Thread 5 connected using MySQL connection ID 64315
** Message: Thread 6 connected using MySQL connection ID 64345
** Message: Thread 7 connected using MySQL connection ID 64275
** Message: Thread 8 connected using MySQL connection ID 64283
** Message: Thread 1 connected using MySQL connection ID 64253
** Message: Thread 2 connected using MySQL connection ID 64211
** Message: Thread 3 connected using MySQL connection ID 64200
** Message: Thread 4 connected using MySQL connection ID 64211
** (mydumper:28829): CRITICAL **: Error: DB: mysql - Could not execute query: Access denied for user 'mysqldbadmin'@'%' to database 'mysql'
** Message: Thread 5 shutting down
** Message: Thread 6 shutting down
** Message: Thread 7 shutting down
** Message: Thread 8 shutting down
** Message: Thread 1 dumping data for `db1`.`TB1`
** Message: Thread 2 dumping data for `db1`.`tb2
….ご覧のとおり、Azureなどの管理対象データベースからのバックアップの取得には制限があります。お気づきかもしれませんが
** (mydumper:28829): CRITICAL **: Couldn't acquire LOCK BINLOG FOR BACKUP, snapshots will not be consistent: You have an error in your SQL syntax; check the manual that corresponds to your MariaDB server version for the right syntax to use near 'BINLOG FOR BACKUP' at line 1これは、SUPERPRIVILEGEがサポートまたは制限されていないためです。理想的には、これを行うための最良のオプションは、Azureデータベースのレプリカからバックアップを取ることです。これについては後で説明します。
この時点で、mydumperは*.gzファイルの形式でバックアップファイルを取得します
-
宛先のオンプレミスサーバーにロードします
$ myloader --host localhost --directory=$(pwd) --queries-per-transaction=10000 --threads=8 --compress-protocol --verbose=3
** Message: 8 threads created
** Message: Creating database `maximusdb`
** Message: Creating table `maximusdb`.`usertbl`
** Message: Creating table `maximusdb`.`familytbl`
** Message: Creating table `db2`.`t1`
** Message: Creating table `db3`.`test1`
…
….-
宛先ノードをスレーブ/レプリカとして設定します。 mydumper will include a file called metadata which consists of binary log coordinates including GTID positions, for example:
$ cat metadata
Started dump at: 2020-10-26 01:35:12
SHOW MASTER STATUS:
Log: mysql-bin.000007
Pos: 801
GTID:0-3649485694-1705
Finished dump at: 2020-10-26 01:37:12##次に、レプリカまたはターゲットの宛先MySQL/MariaDBデータベースノードから変更マスターを実行します
CHANGE MASTER TO MASTER_HOST='<YOUR_AZURE_DB_HOSTNAME>', MASTER_LOG_FILE='mysql-bin.000007', MASTER_LOG_POS=801, MASTER_USER='repl_user', MASTER_PASSWORD='repl_passw0rd';
##スレーブを起動します
START SLAVE;この時点で、MySQL/MariaDBを実行しているAzureデータベースインスタンスからレプリケートされています。アプリケーションをAzureDatabaseインスタンスから移動する準備ができたら、オンプレミスサーバーに移動するエンドポイントをセットアップすると、Azureインスタンスからの残りのすべてのトランザクションがオンプレミスに複製され、オンプレミスにデータが失われることはありません。プレミスサーバー。
AzureでのMySQLまたはMariaDBの管理対象データベースの制限の処理
特にデータセットのバックアップダンプを取得する場合の制限への対処は、バックアップダンプを取得した時点から100％正確である必要があります。もちろん、これはオンプレミスへの理想的な移行です。これに対処するための最良のアーキテクチャ設定は、Azureデータベースにレプリケーショントポロジが存在することです。
移行の準備ができたら、mysqldump/mysqlpumpまたはmydumperはAzureデータベースレプリカをソースとして使用する必要があります。そのAzureデータベースレプリカ内で、SQL_THREADが停止していることを確認して、SHOWSLAVESTATUSの結果から正しいMASTER_LOG_FILEおよびEXEC_MASTER_LOG_POSをスナップショットまたは記録できるようにします。
もちろん、バックアップが完了したら、Azure Databaseレプリカを起動して、レプリケーションスレッドを再開することを忘れないでください。
Azure Databaseインスタンスからレプリカとして機能するオンプレミスサーバーにデータをロードまたはダンプしたら、チェックサム計算を実行してこれを再確認し、データがソースAzureデータベース。 Percona Toolkitのpt-table-checksumツールを使用することをお勧めしますが、md5やsha256などのチェックサムツールを使用して独自のツールを作成することもできますが、これには時間がかかります。さらに、Percona Toolkitからのpt-upgradeを使用すると、このレプリケーションアプローチを使用したデータ移行が完了した後にも役立ちます。
Azure Databaseからの特権とサポートされていないタイプの制限は難しい場合がありますが、適切なフローとアーキテクチャがあれば、オンプレミスのフルマネージドデータベースから移行することは不可能ではありません。必要な手順を準備し、Azure Databaseソースから必要なトポロジをセットアップしてから、バックアップの作成からレプリケーション、およびオンプレミスへの完全な移行への移行を開始するだけです。