レガシー・マイグレーションのノウハウ＆ドゥハウ。 計画時サービスからメインサービスまでシステムズの業務をご案内。

Vol.23　OracleからPostgreSQLへの異種間 DB移行　(その1)

2020.03.31

AWSで実践！異種間DBマイグレーション（Oracle to PostgreSQL編）

DBマイグレーションをテーマに、既存のDBをAmazon Web Service(以下、AWS)のDB環境へ移行する方法論や具体的な実装方法を紹介する本コラムでは、前回（Vol.21 & 22)、Amazon RDSを利用し既存のOracle DBを、Amazon RDS for Oracleへ移行する方法についてご紹介しました。

Amazon RDS を利用することで、Oracle DBのデプロイのセットアップ、運用、スケールをクラウド内で容易に行うことができます。

今回の記事では、Oracle DBのマイグレーションを検討する際に、比較的移行先として取り上げられるケースの多い、オープンソースのリレーショナル・データベース管理システム(RDBMS) PostgreSQLへの移行についてAWSのツールとサービスを活用した移行方法をご紹介します。

はじめに

本記事では、異なる種類の DBをAWSの純正ツールとサービスを利用して、
簡単に移行する方法をご紹介します。

テーブル定義やスキーマ情報などのメタデータは、
AWS Schema Conversion Tool（以下 SCT）を使用して移行し、
テーブル内のレコードは、AWS Database Migration Service（以下 DMS）を使用して移行します。

SCT・DMSの役割のイメージは、
移行元DBと移行先DBを中継し、メタデータやレコードなどの移行を行います。

SCTは、無料のクライアントツールなので、
ローカルPCやEC2インスタンスにインストールして使用します。

DMSは、AWSサービスなので、AWSコンソールから操作しますが、
移行元、移行先DBの中継をするサーバを「レプリケーションインスタンス」といい、DMSのメニューから簡単に構築する事が可能です。

移行の際にかかるコストの大部分は
「レプリケーションインスタンス」のコンピューティングリソースと、
ログストレージに対して発生します。詳しい料金はこちらをご参照ください。

制約事項

SCTは、以下の対応表にあるOLTP変換がサポートされています。
移行対象のDBが該当しているか、確認してからご利用ください。

また、移行先は基本的にAmazo RDSまたは、Amazon Auroraを前提としています。
詳しくはこちらの公式ユーザガイドからご参照ください。

移行元DB	Amazon RDSの移行先DB
Microsoft SQL Server (バージョン 2008 以降)	MySQL と互換性がある Amazon Aurora、PostgreSQL との互換性がある Amazon Aurora、MariaDB 10.2、10.3, Microsoft SQL Server、MySQL、PostgreSQL
MySQL (バージョン 5.5 以降)	Aurora PostgreSQL、MySQL、PostgreSQL AWS SCT を使用せずに、MySQL から Aurora MySQL DB クラスターにスキーマとデータを移行できます。詳細については、「Amazon Aurora DB クラスターへのデータの移行」を参照してください。
Oracle (バージョン 10.2 以降)	Aurora MySQL、Aurora PostgreSQL、MariaDB 10.2 および 10.3、MySQL、Oracle、 PostgreSQL
PostgreSQL (バージョン 9.1 以降)	Aurora MySQL、MySQL、PostgreSQL
IBM Db2 LUW (バージョン 9.1、9.5、9.7、10.5、および 11.1)	Aurora MySQL、MariaDB 10.2 および 10.3、MySQL、PostgreSQL、Aurora PostgreSQL
Apache Cassandra (バージョン 2.0、3.0、3.1.1、および 3.11.2)	Amazon DynamoDB
Sybase (16.0 および 15.7)	Aurora MySQL、Aurora PostgreSQL、MySQL、PostgreSQL

準備（SCT活用編）

移行元DB/移行先DBの作成

本記事では、RDSインスタンスの作成は省略します。
移行元DBは「Oracle 11g」、移行先DBには「PostgreSQL 11.6」を用意しました。

SCTのインストール

こちらから利用するOSに対応したインストーラをダウンロードしてください。
今回は、ローカルのWindowsPCを使用するため、一番上のインストーラを選択しました。

注意点として、SCTから移行元と移行先DBに接続する必要があるため、
ローカルから接続できない環境の場合は、EC2などで構築した中継サーバにインストールする必要があります。

zipを展開して、インストーラを起動します。

SCTのインストールは以上で完了です。

SCTを使用したメタデータの移行

それでは、SCTを使用してOracleの既存のデータベーススキーマを、
PostgreSQLに変換していきます。

プロジェクトの作成

ローカルでSCTを起動した後、Ctrl+N で新規プロジェクトを作成します。

Source database engineは「Oracle」、
Target database engineは「Amazon RDS for PostgreSQL」を選択しました。

OKを押すと、ツール上部に「Connetct to Oracle」と、
「Connect to Amazon RDS for PostgreSQL」が表示されます。

移行元DBへの接続

「Connect to Oracle」を選択して、接続情報を入力します。

ここで注意が必要です。
DB（今回だとRDS）側で、セキュリティグループによる通信許可がされていないと、
下図のように通信エラーが発生します。

AWSコンソールのセキュリティグループから、
RDSに設定しているセキュリティグループのインバウンド設定を許可してやります。

PostgreSQLで使用しているポート 5432も、
後で必要になるので、このタイミングで一緒に設定しました。

もう1度接続してみます。

Oracleに問題なく接続出来る事を確認して、「OK」を押します。

移行先DBへの接続

「Connect to Amazon RDS for PostgreSQL」を押して、
PostgreSQLも同様に入力を行い、接続できる事を確認します。

設定完了後のSCTの画面です。

テスト用に作成した「TESTUSER」スキーマ配下のEMPテーブルと、
VIEW、ファンクション定義を移行していきます。

スキーマの変換

左側の移行元DB上で、移行したいスキーマ（TESTUSER）上で、
右クリックを押して「Convert Schema」を選択します。

もし移行先DBに存在する場合は、
上書いても良いですかというメッセージが表示されるので「Yes」を押します。

右側のPostgreSQLの方に、「testuser」スキーマが表示され、
EMP表、VIEW、ファンクションがツリー配下に並んでいます。

右クリックすると、「Apply to database」と「Save as SQL」があります。
ツリー上には表示されていますが、この時点では、まだPostgreSQL上に反映はされていません。

「Apply to database」を押すと、即時にDDLが適用・反映されます。
まずは「Save as SQL」を押して、DDLの内容を確認してみます。

以下のようなDDLが作成されていました。

-- ------------ Write DROP-FUNCTION-stage scripts -----------

DROP ROUTINE IF EXISTS testuser.tesf(IN DOUBLE PRECISION);

-- ------------ Write DROP-CONSTRAINT-stage scripts -----------

ALTER TABLE testuser.emp DROP CONSTRAINT pk1;

-- ------------ Write DROP-VIEW-stage scripts -----------

DROP VIEW IF EXISTS testuser.test_view;

-- ------------ Write DROP-TABLE-stage scripts -----------

DROP TABLE IF EXISTS testuser.emp;

-- ------------ Write DROP-DATABASE-stage scripts -----------

-- ------------ Write CREATE-DATABASE-stage scripts -----------

CREATE SCHEMA IF NOT EXISTS testuser;

-- ------------ Write CREATE-TABLE-stage scripts -----------

CREATE TABLE testuser.emp(
    emp_no CHARACTER VARYING(10) NOT NULL,
    emp_name CHARACTER VARYING(50),
    gender_f NUMERIC(1,0)
)
        WITH (
        OIDS=FALSE
        );

-- ------------ Write CREATE-VIEW-stage scripts -----------

CREATE OR REPLACE VIEW testuser.test_view (v_emp_no, v_emp_name, gender_f) AS
SELECT
    CONCAT_WS('', a.emp_no, '_V') AS v_emp_no, CONCAT_WS('', a.emp_name, '_V') AS v_emp_name, a.gender_f
    FROM testuser.emp AS a;

-- ------------ Write CREATE-CONSTRAINT-stage scripts -----------

ALTER TABLE testuser.emp
ADD CONSTRAINT pk1 PRIMARY KEY (emp_no);

-- ------------ Write CREATE-FUNCTION-stage scripts -----------

CREATE OR REPLACE FUNCTION testuser.tesf(
     IN dt DOUBLE PRECISION)
RETURNS DOUBLE PRECISION
AS
$BODY$
DECLARE
    d DOUBLE PRECISION;
BEGIN
    d := dt * 2;
    RETURN d;
END;
$BODY$
LANGUAGE  plpgsql;

もし移行時に一部の定義を変更したい場合などは、
このDDLを編集して利用する方法もありますが、今回はSCT上でそのまま適用していきます。

変換の適用

「Apply to database」を選択します。

「Yes」を押して、移行先DBへの適用完了です。

この時点では、スキーマやテーブル定義などは作られていますが、
テーブルのレコードはまだ存在しません。この後DMSを使って移行していきます。

次回は、AWS Database Migration Service (以下、DMS)を活用した移行をご紹介します。
(次回のコラムに続く)