AWS
oracle
RDS
DMS

AWS DMSでオンプレミス OracleSE1からRDS for OracleSE1移行時のハマったところなど

はじめに

現在弊社ではシステムを非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ヶ月で出来ました

DMSバンザイ!