2021年12月20日 DB、MySQL、RDS コメントする

MySQL Shell Dump Loading UtilityとMySQLネイティブレプリケーションを利用してスマートにRDS Auroraへのデータベース移行を行う

この投稿はアイスタイル Advent Calendar 2021 の20日目の記事です。

こんにちは！アイスタイルでインフラ・DBAをやっているiwasakikです。

アイスタイルでは現在クラウドの導入が進んでおり、これまでオンプレミスで運用してきていたデータベースサーバーにつきましては、AWS環境への移行を実施しております。
その中でも今回はオンプレミスで運用しているMySQLのデータベースサーバーをAWSのRDS Aurora環境へ移行する方法ついて記事にさせていただきました。
今回の記事のメインとなるMySQLの機能としては、比較的リリースタイミングが新しいMySQL標準のツールであるInstance Dump Utility and Dump Loading Utilityとなります。

目次

  • オンプレミスMySQLをAuroraへ移行する方法と利用できるツールについて
  • 検証内容について
  • 検証に成功した移行方法のご紹介
    • オンプレミスMySQL側（移行元）の準備
      • MySQL Shellのインストール
      • MySQL ShellのInstance Dump Utilityを利用して移行元であるオンプレミスMySQLのバックアップを取得する
    • RDS Aurora（移行先）の準備
      • ネットワーク周り、セキュリティグループの設定（移行元であるオンプレミスMySQLと疎通できるように）
    • Auroraクラスターの構築
      • Auroraクラスター/インスタンスの作成
      • MySQL ShellのDump Loading Utilityを利用してAurora上にデータベースをリストアする
      • DBユーザー情報をインポートする
      • ユーザー・イベントスケジューラのイベント・ストアドプロシージャーおよびストアドファンクション・テーブルのトリガーを移行
    • レプリケーションの構築
      • バイナリログを利用したオンプレミスMySQLからAurora環境へのレプリケーションの構築
    • オンプレミスMySQLからAuroraへの切り替え
      • オンプレミスMySQLからAuroraへ切り替える際のレプリケーション停止とAuroraのマスタ昇格
      • アプリケーションからの向き先を移行先のAuroraクラスターへ変更する
  • Percona XtraBackupを利用した手法との比較
  • まとめ
  • さいごに

オンプレミスMySQLをAuroraへ移行する方法と利用できるツールについて

今回オンプレミスのMySQLをAuroraへ移行するにあたって環境切替え時のダウンタイムを最小限に抑える方法を検討しました。

方法としてはまず、オンプレミスのMySQLのバックアップから移行先のAuroraクラスターへデータベースを復元してバイナリログレプリケーションを組んでデータを転送し続けます。
そして、環境を切り替える際にアプリケーションサーバーからデータベースへの向け先を既存のオンプレミスMySQLから移行先となるAuroraへの切り替える事で移行を実施します。

Aurora環境へ既存のオンプレミスのMySQLのデータベースを復元するための方法として利用できるツールは下記の3つが挙げられます。

1. Percona XtraBackup

Percona社が公開しているオープンソースのバックアップツールとなります。
こちらはmysqldumpのようにバックアップをSQLの形式として出力する論理バックアップではなく物理バックアップとなります。

2. mysqldump

mysqlに標準でインストールされているバックアップツールです。
バックアップをSQLの形式として論理バックアップを取得できます。

3. Instance Dump Utility and Dump Loading Utility

2020年7月13日にリリースされたMySQL Shellのバージョン8.0.21より機能追加されたバックアップのスレッドを並列化させてパラレルで実行する機能と、そのバックアップを同じくパラレルでインポートするユーティリティです。
MySQL Shellがインストールできる環境であれば、mysqlのバージョン8系に限らずmysqlバージョン5.7系でも5.6系でも利用できるという優れものです。

AWSの公式ドキュメントでは外部の MySQL データベースから Amazon Aurora MySQL DB クラスターへのデータ移行を行う際に、上記のうち1のPercona XtraBackupと2のmysqldumpを利用してAuroraへのデータベース環境の復元を行う手法が紹介されておりましたが、Percona XtraBackupはS3バケットを経由する事やそれに伴うIAMロールの作成などが必要で作業が複雑化してしまうということ、mysqldumpについて手法が細かく記載されていなかったので、今回はInstance Dump Utility and Dump Loading Utilityをデータベース環境を復元するツールとして利用しました。

Percona XtraBackupを利用してInstance Dump Utility and Dump Loading Utilityを利用した際のメリット・デメリットは後述いたします。

それでは次の項目より検証内容をご紹介させていただきます。

検証内容について

今回の検証内容としましては、オンプレミスのMySQLインスタンスのバックアップをInstance Dump Utility and Dump Loading Utilityを利用して取得し、そのバックアップを元にデータベースインスタンスをRDS Auroraに復元します。
その後、オンプレミスのMySQLをSOURCE、Aurora環境をREPLICAとしてレプリケーションを組み、環境を切り替えるというものです。

参考までに移行元のオンプレミスMySQLサーバーのOSおよびMySQLバージョンは下記の通りです。

Linux OSバージョン：CentOS Linux release 7.4.1708 (Core)
MySQLバージョン：5.7.22

結果として、検証は成功しましたのでその手法を下記に記します。

検証に成功した移行方法のご紹介

前提条件：移行元であるMySQLインスタンスが存在するオンプレミスサーバーからRDS環境へネットワークの疎通が取れていること

オンプレミスMySQL側（移行元）の準備

MySQL Shellのインストール

  1. リポジトリのダウンロードとインストール（CentOS7向け）
$ wget http://dev.mysql.com/get/mysql80-community-release-el7-3.noarch.rpm
$ sudo rpm -Uvh mysql80-community-release-el7-3.noarch.rpm
  1. yumを利用してMySQL Shellのインストール
$ sudo yum install mysql-shell -y
  1. インストールできたか確認（バージョンが表示されたらOK！）
$ mysqlsh -V
mysqlsh   Ver 8.0.27 for Linux on x86_64 - for MySQL 8.0.27 (MySQL Community Server (GPL))

MySQL ShellのInstance Dump Utilityを利用して移行元であるオンプレミスMySQLのバックアップを取得する

  1. MySQL ShellコマンドにてオンプレミスMySQLのローカルインスタンスへログインする
$ mysqlsh root@127.0.0.1
MySQL Shell 8.0.27

Copyright (c) 2016, 2021, Oracle and/or its affiliates.
Oracle is a registered trademark of Oracle Corporation and/or its affiliates.
Other names may be trademarks of their respective owners.

Type '\help' or '\?' for help; '\quit' to exit.
Creating a session to 'root@127.0.0.1'
Fetching schema names for autocompletion... Press ^C to stop.
Your MySQL connection id is 78509658
Server version: 5.7.22-log MySQL Community Server (GPL)
No default schema selected; type \use <schema> to set one.
 MySQL  127.0.0.1:3306  JS >
  1. MySQL ShellのInstance Dump Utilityを利用してローカル上にバックアップを取得する
#ドライラン実行してエラー出ないことをまず確認
 MySQL  127.0.0.1:3306  JS > util.dumpInstance( "/export/iwasakik/mybackup" , {dryRun: true,events: false, routines: false, triggers: false})


#実行
 MySQL  127.0.0.1:3306  JS > util.dumpInstance( "/export/iwasakik/mybackup" , {events: false, routines: false, triggers: false})


実行ログ）
 MySQL  127.0.0.1:3306  JS > util.dumpInstance( "/export/iwasakik/mybackup" , {events: false, routines: false, triggers: false})
Acquiring global read lock
Global read lock acquired
Initializing - done
Gathering information - done
All transactions have been started
Locking instance for backup
NOTE: Backup lock is not supported in MySQL 5.7 and DDL changes will not be blocked. The dump may fail with an error or not be completely consistent if schema changes are made while dumping.Global read lock has been released
Writing global DDL files
Writing users DDL
（中略）
Writing schema metadata - done
Writing DDL - done
Writing table metadata - done
Starting data dump
99% (527.27K rows / ~528.12K rows), 578.90K rows/s, 110.65 MB/s uncompressed, 9.97 MB/s compressed
Dump duration: 00:00:01s
Total duration: 00:00:01s
Schemas dumped: 4
Tables dumped: 502
Uncompressed data size: 106.59 MB
Compressed data size: 10.75 MB
Compression ratio: 9.9
Rows written: 527266
Bytes written: 10.75 MB
Average uncompressed throughput: 101.35 MB/s
Average compressed throughput: 10.22 MB/s

RDS Aurora（移行先）の準備

ネットワーク周り、セキュリティグループの設定（移行元であるオンプレミスMySQLと疎通できるように）

  1. ネットワーク周りの設定については対象のAWSアカウントのVPC環境と移行元オンプレミス環境との間でDirect ConnectやVPN接続などができる環境を準備しておいてください（ここでは詳細は省略）

  2. 移行元オンプレミス環境のサーバーから接続可能とするように、Aurora側のセキュリティグループではインバウンドルールでオンプレミスサーバーのIPアドレスからのポート3306の通信を登録しておいて下さい

Auroraクラスターの構築

Auroraクラスター/インスタンスの作成

Aurora環境を構築するAWSアカウント上に移行先のデータの受け皿となるRDS Auroraクラスターを構築する（今回は手動構築）

  1. AWSマネジメントコンソールより、RDSサービスのコンソールへ遷移し、左ペインの「データベース」を選択し、「データベースの作成」を選択する

  2. データベースの作成画面にて各種設定を行い、下記の項目を設定してください。その他の項目は各自のデータベース要件に応じて設定する

    エンジンのタイプ：Amazon Aurora
    エディション：Amazon Aurora MySQL 互換エディション
    利用可能なバージョン：Aurora (MySQL 5.7) 2系　もしくは　Aurora MySQL 3系
    ※2系と3系で環境構築の内容が少し異なるのでご注意ください。後述します。

  3. 各種設定が完了したら「データベースの作成」を選択し、Auroraクラスターの作成を開始する。サイズ等にもよるが数分程度で完了する。ステータスが「利用可能」になったら作成完了

MySQL ShellのDump Loading Utilityを利用してAurora上にデータベースをリストアする

  1. RDSサービスのコンソールより上記で構築した移行先のAuroraクラスターの設定画面へ遷移し、クラスターのエンドポイントをメモする

  2. 移行元オンプレミス環境のサーバーへsshログインし、MySQL Shellコマンドにて上記でコピーしたAuroraクラスターのエンドポイントへ管理者ユーザーでログインする
    ※ここまでの手順でオンプレのローカル環境へMySQL Shellインストール、オンプレ・Aurora間で接続できるようネットワーク周りの設定も済んでいるのが前提

$ mysqlsh admin@<Auroraクラスターのエンドポイント>
MySQL Shell 8.0.27

Copyright (c) 2016, 2021, Oracle and/or its affiliates.
Oracle is a registered trademark of Oracle Corporation and/or its affiliates.
Other names may be trademarks of their respective owners.

Type '\help' or '\?' for help; '\quit' to exit.
Creating a session to 'admin@<Auroraクラスターのエンドポイント>'
Fetching schema names for autocompletion... Press ^C to stop.
Your MySQL connection id is 288
Server version: 8.0.23 Source distribution
No default schema selected; type \use <schema> to set one.
 MySQL  <Auroraクラスターのエンドポイント>:3306 ssl  JS >
  1. MySQL ShellのDump Loading Utilityを利用してAurora上にデータベースをリストアする
    ここまでの手順で取得したオンプレMySQLのバックアップをAuroraへリストアする。リストア先がAurora MySQL 2(MySQL 5.7)系とAurora MySQL 3(MySQL 8.0)系とでコマンドが一部異なるので注意

リストア先がAurora MySQL 2(MySQL 5.7)系の場合

MySQL  <Auroraクラスターのエンドポイント>:3306 ssl  JS > util.loadDump("/export/iwasakik/mybackup")
Loading DDL and Data from '/export/iwasakik/mybackup' using 4 threads.
Opening dump...
Target is MySQL 5.7.12. Dump was produced from MySQL 5.7.22-log
Scanning metadata - done
Checking for pre-existing objects...
Executing common preamble SQL
Executing DDL - done
Executing view DDL - done
Starting data load
4 thds loading / 100% (106.48 MB / 106.48 MB), 219.29 KB/s, 427 / 501 tables done
Recreating indexes - done
Executing common postamble SQL
501 chunks (526.39K rows, 106.48 MB) for 501 tables in 4 schemas were loaded in 53 sec (avg throughput 4.48 MB/s)
0 warnings were reported during the load.

リストア先がAurora MySQL 3(MySQL 8.0)系の場合　ignoreVersionオプションを指定する必要がある

MySQL  <Auroraクラスターのエンドポイント>:3306 ssl  JS > util.loadDump("/export/iwasakik/mybackup7", {ignoreVersion: true})
Loading DDL and Data from '/export/iwasakik/mybackup' using 4 threads.
Opening dump...
Target is MySQL 8.0.23. Dump was produced from MySQL 5.7.22-log
WARNING: Destination MySQL version is newer than the one where the dump was created. Loading dumps from different major MySQL versions is not fully supported and may not work. The 'ignoreVersion' option is enabled, so loading anyway.
Scanning metadata - done
Checking for pre-existing objects...
Executing common preamble SQL
Executing DDL - done
Executing view DDL - done
Starting data load
4 thds loading - 100% (106.57 MB / 106.57 MB), 220.68 KB/s, 432 / 502 tables done
Recreating indexes - done
Executing common postamble SQL
502 chunks (527.19K rows, 106.57 MB) for 502 tables in 4 schemas were loaded in 51 sec (avg throughput 4.68 MB/s)
0 warnings were reported during the load.

※オンプレミスとAuroraのMySQL互換性バージョンが異なる際の注意点

今回移行元オンプレミスMySQLのバージョンがMySQL5.7系のため、移設先のAuroraクラスターのバージョンがAurora MySQL 3系になってしまうと、互換性バージョンがMySQLバージョン8.0となりメジャーバージョンを跨いだ移設となるためダンプロード時に追加でオプションが必要になります。

何も指定しなかった場合は、下記の通りエラーとなりオンプレミスMySQL5.7系からAurora MySQL 3系にはダンプのロードができませんでした。
ERROR: Destination MySQL version is newer than the one where the dump was created. Loading dumps from different major MySQL versions is not fully supported and may not work. Enable the ‘ignoreVersion’ option to load anyway.
Util.loadDump: MySQL version mismatch (RuntimeError)

上記のコマンドの通り{ignoreVersion: true}とオプションを指定してロードを実施するとメジャーバージョン違いますよーってWARNINGが出ますが、ロード実施できます。

MySQL ShellではMySQL Shell アップグレードチェッカユーティリティ checkForServerUpgrade() という便利な互換性チェックコマンドがあるので事前に移設元のオンプレミスMySQL5.7系でこちらのコマンドを実施して互換性に問題がないか確認するようにしましょう。
参考：ダンプロードユーティリティ：ignoreVersion

DBユーザー情報をインポートする

今回のMySQL ShellのInstance Dump Utilityではinformation_schema, mysql, ndbinfo, performance_schema および sys スキーマはインスタンスダンプから除外されるため、mysqlデータベースに格納されているDBユーザー情報はロードしても新環境に引き継がれません。

information_schema, mysql, ndbinfo, performance_schema および sys スキーマは、常にインスタンスダンプから除外されます。 mysql.apply_status, mysql.general_log, mysql.schema テーブルおよび mysql.slow_log テーブルのデータは、DDL ステートメントは含まれますが、常にスキーマダンプから除外されます。 ユーザーとそのロール、権限付与、イベント、ルーチンおよびトリガーを含めるか除外するかを選択することもできます。

参考：MySQL Shell 8.0 / MySQL Shell ユーティリティ / インスタンスダンプユーティリティ、スキーマダンプユーティリティおよびテーブルダンプユーティリティ

そのため、移行元であるオンプレミスMySQLのDBユーザー情報を移行先で引き継ぐためには、下記のようにダンプ実施時に別ファイルに出力されるユーザー情報ファイルからインポートする必要があります。
今回のようにdumpの出力先を/export/iwasakik/mybackupに指定した場合、DBユーザー情報ファイルは下記のファイルに出力されております。

/export/iwasakik/mybackup/@.users.sql
  1. ユーザー情報をインポートするコマンドを実行する
MySQL  <Auroraクラスターのエンドポイント>:3306 ssl  SQL > source /export/iwasakik/mybackup/@.users.sql

ユーザー・イベントスケジューラのイベント・ストアドプロシージャーおよびストアドファンクション・テーブルのトリガーを移行

ストアドプロシージャ、トリガー、関数、イベントがインスタンスダンプに含まれていると、
ERROR: [Worker001] While executing DDL for schema ripico: Access denied; you need (at least one of) the SUPER privilege(s) for this operation
というようにAuroraのマスターユーザーではSUPER権限が与えられていないのでエラーとなりリストアが失敗したので（Aurora MySQL 2(MySQL 5.7)系で確認）、今回util.dumpInstanceコマンド実行時にそれらを省くよう下記のオプションを入れました。

{events: false, routines: false, triggers: false}

今回のデータベース移行方法では、これらのオブジェクトは別途移行する必要があるので下記のコマンドを参考に移行元MySQLにおいてその存在を確認し、個別に構築クエリを実行してください。

情報抽出クエリ

イベントスケジューラのイベント

use <確認対象のDB>;
show events\G;

ストアドプロシージャーおよびストアドファンクション

SELECT
  ROUTINE_SCHEMA, /* ストアドプロシージャがあるデータベース */
  ROUTINE_NAME,   /* ストアドプロシージャの名前 */
  ROUTINE_TYPE    /* プロシージャとファンクションのどちらかを示す */
FROM
  information_schema.ROUTINES;

テーブルのトリガー

SHOW TRIGGERS FROM <データベース名称>;

レプリケーションの構築

移行元のオンプレミスMySQLから上記で復元したAuroraインスタンスに対してレプリケーション設定を行う方法を記載します。

今回の手順では非暗号化レプリケーションの設定方法となります。

  1. ソースのオンプレ側MySQLの設定がレプリケーションに適した設定になっているか下記のクエリを実行して必要な設定値になっているか確認します。　実行先：ソース（移行元）
MySQL > SELECT @@GLOBAL.log_bin;
MySQL > SELECT @@GLOBAL.server_id;
MySQL > SELECT @@GLOBAL.innodb_flush_log_at_trx_commit;
MySQL > SELECT @@GLOBAL.sync_binlog;

必要な設定値

# 設定項目 必要な設定値
1 log_bin 1
2 server_id 数値が入っていること
3 innodb_flush_log_at_trx_commit 1
4 sync_binlog 1

確認コマンド実行例

MySQL  127.0.0.1:3306  SQL > SELECT @@GLOBAL.log_bin;
+------------------+
| @@GLOBAL.log_bin |
+------------------+
|                1 |
+------------------+
1 row in set (0.0001 sec)
 MySQL  127.0.0.1:3306  SQL > SELECT @@GLOBAL.server_id;
+--------------------+
| @@GLOBAL.server_id |
+--------------------+
|              32963 |
+--------------------+
1 row in set (0.0003 sec)
 MySQL  127.0.0.1:3306  SQL > SELECT @@GLOBAL.innodb_flush_log_at_trx_commit;
+-----------------------------------------+
| @@GLOBAL.innodb_flush_log_at_trx_commit |
+-----------------------------------------+
|                                       1 |
+-----------------------------------------+
1 row in set (0.0003 sec)
 MySQL  127.0.0.1:3306  SQL > SELECT @@GLOBAL.sync_binlog;
+----------------------+
| @@GLOBAL.sync_binlog |
+----------------------+
|                    1 |
+----------------------+
1 row in set (0.0002 sec)
  1. ソースのオンプレミスMySQLにレプリケーション用のユーザーを作成します。　実行先：ソース（移行元）
MySQL > CREATE USER repl@'%' IDENTIFIED BY '********';
MySQL > GRANT REPLICATION CLIENT, REPLICATION SLAVE ON *.* TO repl@'%';
  1. レプリカとなるAuroraクラスターのレプリケーションを開始するバイナリログの位置を確認します。　実行先：レプリカ（移行先）

    3-1.AWS Management Console にサインインし、Amazon RDS コンソール (https://console.aws.amazon.com/rds/) を開きます。

    3-2.ナビゲーションペインの [Events] を選択します。

    3-3.[イベント] リストで、[Recovered from Binary log filename (バイナリログのファイル名から復旧済み)] イベントの位置をメモします。

    ※ここではバイナリログファイル名：mysql-bin.000032,バイナリログポジション：298059756をメモしておきます。

    3-3.レプリカとなるAuroraクラスターのmysqlサーバーにmysqlクライアントなどで接続し、ソースに対するレプリケーションの要求設定を行います。下記のストアドプロシージャ、コマンド群を実行してください。　実行先：レプリカ（移行先）

    3-3-1.mysql.rds_set_external_master ストアプロシージャを実行して、バイナリログレプリケーションを有効化します。ストアドの構文は下記の通り。

    CALL mysql.rds_set_external_master (
host_name                             <--ソースであるオンプレMySQLのIPアドレスもしくはホスト名を指定
, host_port                           <--MySQLなので3306
, replication_user_name               <--この手順の前の方で作成したレプリケーション用ユーザーを指定
, replication_user_password           <--レプリケーション用ユーザーのパスワードを指定
, mysql_binary_log_file_name          <--上記3-3で確認したバイナリログファイル名を指定
, mysql_binary_log_file_location      <--上記3-3で確認したバイナリログポジションを指定
, ssl_encryption                      <--暗号化するかどうかを0,1のどちらかで指定。今回の手順は暗号化しないので0を指定。
);

    3-3-2.mysql.rds_start_replication ストアプロシージャを実行して、バイナリログレプリケーションを開始します。

    CALL mysql.rds_start_replication;

    3-3-3.SHOW SLAVE STATUSコマンドを実行してレプリケーションが成功しているか、レプリケーションがどれくらい遅れているかを確認します。

    ※ステータスが下記になっていれば、レプリケーションが成功しています。おめでとうございます。
    Slave_IO_Running: Yes
    Slave_SQL_Running: Yes

    実行コマンド

    show slave status\G;

オンプレミスMySQLからAuroraへの切り替え

上記までの設定でオンプレミスMySQLのデータをAuroraへ同期し続ける仕組みの構築は完了しました。
実際にオンプレミスMySQLからAuroraへの切り替えを実施する際は、アプリケーションからの接続を停止してレプリケーション停止、マスター昇格をする必要があります。
データベースに対する更新を確実に停止して、下記コマンドを実行し、アプリケーションからの向き先をAurora側に切り替えて移行完了となります。

オンプレミスMySQLからAuroraへ切り替える際のレプリケーション停止とAuroraのマスタ昇格

  1. オンプレミスMySQLからAuroraに対するレプリケーション停止するために下記ストアドを実行してください。　実行先：レプリカ（移行先）
    ストアドの構文
CALL mysql.rds_stop_replication;
  1. Auroraマスタ昇格（ただslaveじゃない状態にするだけですが）を行うために、レプリケーションの状態を下記ストアドを実行してリセットしてください。
    ストアドの構文
CALL mysql.rds_reset_external_master;

アプリケーションからの向き先を移行先のAuroraクラスターへ変更する

データベースに接続している各種アプリケーションからの接続先を移行元のオンプレミスMySQLから移行先であるAuroraクラスターへ向けて移行完了となります。

Percona XtraBackupを利用した手法との比較

今回MySQL ShellのInstance Dump Utilityを利用して移行環境を作成する事で、Percona XtraBackupを利用して環境移行を行うのに必要な下記の作業を省略する事ができました。

- オンプレミス環境へのPercona XtraBackupのインストール
- バックアップ復元用のS3バケットの作成
- S3バケットへのバックアップファイルのアップロード
- S3とAuroraがやりとりするのに必要なIAMポリシー・IAMロール・パラメータグループの作成

ただ、Percona XtraBackupは物理バックアップからの復元となるのでMySQL ShellのInstance Dump Utilityでは個別に実施したDBユーザーの移行やイベントスケジューラのイベント、ストアドプロシージャーおよびストアドファンクション、テーブルのトリガーの個別での作成が不要でした。

まとめ

今回の検証では、オンプレミスのMySQLからAuroraへデータ移行するにあたってダウンタイムの少ない最適な手法を模索することができました。
MySQL ShellのInstance Dump Utilityを利用したデータ移行はAWS側へのS3やIAM権限の設定などが不要になり、ユーザーやストアドなどは個別に移設する必要がありますが簡単なコマンドで実施する事が可能なことが分かりました。
また、上記の事が把握できたことでAWS環境にS3やIAMの設定を行うのが得意なユーザーであればPercona XtraBackupの物理バックアップを利用したデータ移行の手法も利用価値がある事が判明しました。
それぞれの手法にはやはりメリット・デメリットがあり、状況や得意分野に応じてデータ移行方法は選択していくべきだと思いました。
今後よりスムーズにデータ移行できるツールがリリースされることも期待しております。

さいごに

昨年のアドベントカレンダーではさまざまなMySQLのバックアップ手法とその性能差についてご紹介させていただきましたが、今年はそれに加えてAWS環境へのデータ移行への利用という観点からこの記事を書かせていただきました。
1年という短い期間でこのようにさまざまな環境に触れて、新しい技術に関われているので僕にとっては探求心がつきません。
ご紹介させていただいた内容には、手作業が多いので今後はTerraformなどを用いてコード化し、より作業者の手を煩わせないような仕組みを構築していきたいと考えております。
まだまだ勉強中ですが、クラウド化の波を超えてさまざまな知識や発見をした際には、その内容をご紹介させていただく記事を書いていきたいと思いますので引き続きどうぞよろしくお願いいたします！

iwasakik
2019年7月入社のアイスタイルのDBA・インフラエンジニアです。 ダンスとかDJとかファンキーなものを好みます。

おすすめ

  1. SQL Serverをクラウドへ移行する（立志編）

    2021年12月22日

  2. データベースの暗黙的型変換のお話し

    2021年12月7日

  3. A5:SQLを使って、テーブル定義書を自動で作成してみた話

    2021年12月4日

コメントを残す