はじめに
現在弊社ではシステムを非AWS環境からAWSに移行する作業をしております
本記事は、AWS移行作業の一部であるDB移行を、AWS DMSで行った際に遭遇したつまずきポイントなどをまとめます
目次
- DMS側のつまずきポイント
- レプリケーションインスタンスのインスタンスクラス問題
- 新機能のデータ検証使えない問題
- インスタンスごとのエンドポイント設定数制限問題
- ソースDB側のつまずきポイント
- 社内セキュリティポリシーの問題
- 1日たったら変更データキャプチャ (CDC) 動かなくなる問題
- ターゲットDB側のつまずきポイント
- 適切なRDSのスペック選定問題
- データベースリンクの問題
- ユーザー作成＋シーケンスの問題
DMS側のつまずきポイント
レプリケーションインスタンスのインスタンスクラス問題
DMSを初めて触るに辺りお試しで移行しようと思い、ケチってレプリケーションインスタンスのインスタンスクラスをmicroで作ったのですが、これがまずかったです
microインスタンスだと100%エラーが発生し、タスクが失敗しました
設定自体は完璧なのにタスクが実行できず、以下のようなエラーログが出たら、インスタンスクラスをアップグレードすることをおすすめします
Task error notification received from subtask 0, thread 0 [XXXXXX] Oracle CDC maximum retry counter exceeded.
Task 'XXXXXXXXXXXXXXXXXXXXXXX' encountered a fatal error
新機能のデータ検証使えない問題
移行作業中にDMSの機能がアップグレードし、移行前のタスク評価と移行後のデータ検証が使えるようになりましたので、早速データ検証を使ってみた所ハマりました
データ検証を使用するにはレプリケーションエンジンのバージョンを2.4.0（東京リージョンの場合）にする必要があります
レプリケーションエンジンの2.4.0バージョン情報は、本記事作成時点では公式マニュアルに記載されていませんでした
使うにはタスク設定画面の検証の有効化をONにすることで使えるようです
ただうちの環境でここをONにすると、そのタスクは100%失敗しました
CloudWatchのログには以下のように出てます
Cannot get special table's id for table awsdms_validation_failures
公式マニュアルによると、検証の有効化をONにするとターゲットDBに「awsdms_validation_failures」というテーブルを作るようです
このテーブルには診断情報を書き込むようで、検証エラーのトラブルシューティングに使えるようなのですが、このテーブルすら作られていませんでした
また、一度検証の有効化をONにすると、タスク編集でOFFにして再度タスク実行しようとしても、そのタスクは以降ずっと失敗するようになりました
公式記載の制限事項はクリアしていたかと思いますが、原因がわからなかったので、検証機能は使わないようにしました
インスタンスごとのエンドポイント設定数制限問題
DMSには結構作成リソースの制限が厳しいです
以下公式記載の東京リージョンでの制限値です
| リソース | デフォルトの制限 |
|---|---|
| レプリケーションインスタンス | 20 |
| ストレージの合計 | 6TB |
| イベントサブスクリプション | 100 |
| レプリケーションサブネットグループ | 20 |
| レプリケーションサブネットグループあたりのサブネット | 20 |
| エンドポイント | 100 |
| タスク | 200 |
| インスタンスごとのエンドポイント | 20 |
今回DB移行する対象のサービスは、DB4台のスキーマ数100以上でした
レプリケーションインスタンスは2台だったので、エンドポイントを作っては消し、作っては消し…を繰り返しました
後からレプリケーションインスタンスの数を増やすことが社内事情で難しかったため、もし大量の移行作業をする場合は、予めレプリケーションインスタンスを大量に作っておいたほうがいいでしょう
ソースDB側のつまずきポイント
社内セキュリティポリシーの問題
AWSに移行前の環境では、DBに関してのレコード操作以外の作業はすべてDBGという部署が管理していました
- GIPを割り当てることNG
- root権限使用NG
- VPC環境外からのDB接続NG
- スキーマ・ユーザー作成NG
制限だらけです
AWS外の環境からDMSを使って移行する場合、AWS Direct Connectや、VPN接続といった複数のオプションを使用して繋ぐ方法もありますが、GIPでの接続が一番簡単で安価です
また、DMSを使うための専用ユーザーを作る必要もあります
OracleをソースとしてDMSを使う場合は、ARCHIVELOGモードやサプリメンタルロギングをオンに設定する作業もありますし、ポリシーと相違する事だらけです
ここの対応をお願いする調整が大変でした
DBGに対応依頼をしても「無理です」の一点張りになりますので、一番偉い人に土下座してお願いするのが手っ取り早いです
1日たったら変更データキャプチャ (CDC) 動かなくなる問題
今回のDB移行作業は1つのタスクを1日以上実行しっぱなしにすることはないのですが、たまたま作業が日をまたいだ時がありました
出社してタスクの状況を見たらタスクが止まっており、何故かを調べた所1日1回DBのセッションをリフレッシュする処理が入ってました
この処理を止めることは社内ルールとしてできなかったため、「1日以上かかるタスクは作らない」という運用でカバー（魔法の言葉）しました
ターゲットDB側のつまずきポイント
適切なRDSのインスタンスクラス選定問題
旧環境ではかなり余裕を見たテーブルスペースサイズをそれぞれのスキーマーに割り当てており、正式な必要ディスク領域を算出することが難しかったです
単にDBのHDD使用量を見るだけではわからないということです
データベースリンクの問題
旧環境では一部スキーマにDatabase linkがLIPで設定されていました
当然RDSからは使えないのでここの修正が必要です
Database linkの問題はすぐに気が付かなかったので、検証・調査に結構時間がかかりました
ユーザー作成＋シーケンスの問題
DMSはセカンダリインデックス、シーケンス、デフォルト値、ストアドプロシージャ、トリガー、シノニム、ビューなど、データ移行に特に関係ないスキーマオブジェクトは移行しません（公式マニュアル）
また、ターゲットDBにスキーマを作成してくれません（公式マニュアル）
なので一個一個のスキーマ、シーケンス等を作成するSQLを作り、RDS Oracleに作る作業が面倒でした
以上、色々つまずきましたがDMSのお陰で、4つのDB、100位上のスキーマの移行作業が、サービス停止すること無く1ヶ月で出来ました