[レポート]GPSCT406:OracleからAurora PostgreSQLへの移行に関するベストプラクティスとデザインパターン #reinvent

GPSCT406 - OracleからAurora PostgreSQLへの移行に関するベストプラクティスとデザインパターン に参加したレポートをお届けします。
2018.12.03

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

こんにちは。コンサルティング部の崔です。

GPSCT406:Migrate from Oracle to Aurora PostgreSQL: Best Practices, Design Patterns, & Setup に参加しましたのでレポートをお届けします。

OracleからAurora PostgreSQLへの移行のヒントになれば幸いです。 また、このトラックはChalk Talk形式でした。前半はスライドで説明しながら、ときおりホワイトボードへの板書・QAを交え、後半はたっぷり時間をとってQAを行うものでした。

セッション概要

In this session, we show you how to set the source Oracle database environment, the target PostgreSQL environment, and parameter group configuration. We also recommended database parameters to disable foreign keys and triggers. Finally, we discuss best practices for using AWS Database Migration Service (AWS DMS) and AWS Schema Conversion Tool (AWS SCT) and show you how to choose the instance type and configure AWS DMS.

ソースDBのOracleやターゲットDBのPostgreSQLについて、また、AWS DMSやAWS SCTを利用するベストプラクティスについて、お話します。

スピーカー

  • Mahesh Pakala - Senior Solutions Architect, Amazon Web Services

セッションメモ

まず、最初に公式ブログが紹介されていました。 Amazon Web Services ブログ:Oracle データベースを Amazon RDS PostgreSQL または Amazon Aurora PostgreSQL に移行するベストプラクティス: 移行プロセスとインフラストラクチャに関する考慮事項 このブログがセッションのベースとなっているようです。

  • アジェンダ
    • イントロ
    • 計画フェーズ
    • ソースDBの推奨設定
    • DMSプロセス
    • ターゲットDB:PostgreSQLの推奨設定
    • デザインガイドライン
    • サマリー
  • 計画フェーズ
    • このフェーズが最も重要
    • スキーマ移行の複雑さを判定する
    • オブジェクトの種類や数、サイズから複雑さを点数化する
      • オブジェクトのタイプによる点数の違い
      • オブジェクトごとの数
      • それぞれの点数と個数から合計点を計算
    • 1時間あたりのRedoログのサイズから点数算出
    • これらから、S/M/Lと判定する

  • Workload Qualification Framework(WQF)の紹介
    • WQFはセルフサービスのツール、アンケート、設計レビューのガイダンスが含まれている
    • これらを利用することで、ワークロードの分類、移行の難易度の決定、必要な人月、移行先のAWSサービスを決定できる
    • WQFはOLTPとDWHの2種類のワークロードを5つのカテゴリーに分類している。

カテゴリー ワークロードの種類 移行の難易度 必要な人月
1 ODBC/JDBCのワークロード
2 軽度のOracle機能のワークロード
3 Oracle機能の重度のワークロード
4 Oracle固有のアプリケーションフレームワーク 移行は困難 N/A
5 OCIのワークロード
  • ソースDBのOracle設定について
    • サーバセットアップ
      • Infrastructure security
      • Network I/O rates, transfers, and read/write ratios
    • データベース
      • Oracle account access for the replicate user
      • Archive logging
      • Supplemental logging
  • ソースサーバーのメトリクス
    • CPU使用率
    • メモリー使用量
    • kernel statistics and run queue information
    • DISKs I/O rates, transfers, and read/write ratios
    • ファイルシステムの空き容量
    • Disk adapters
    • Paging space and paging rates
    • Network I/O rates,transfers, and read/write ratios
    • ソース側のCPU使用率、メモリー使用量、I/Oパターンも重要だが、特にネットワークのパフォーマンスは忘れてはならない。
  • AWS DMS process
    • Oracleログを読むためのDMSメソッド
      • Oracle Log Miner
        • Oracleデータベースに対する変更を記録
      • Binary Reader
        • Oracle Redo ログを解析
  • AWS Database Migration Service(AWS DMS)
    • Full LOAD
    • Change Data Capture

  • ターゲットDBのPostgreSQLセットアップ
    • Disable
      • DB インスタンスのバックアップ(set BACKUP_RETENTION to 0)
      • Multi-AZ :同期レプリケーションによる遅延を回避するため
      • SYNCHRONOUS_COMMIT BUT noy FSYNC
    • Do NOT Disable AUTOVACUUM
    • Do NOT Modify VACUUM_FREEZE_MIN_AGE
    • VACUUM ANALYZE after initial load to keep latest statistics
    • Adjust the logging default to be more VERBOSE
    • SHARED_BUFFERS
      • EFFECTIVE_CACHE_SIZE
      • PG_BUFFERCACHE
    • MAX_CONNECTIONS
      • Hard Limit
    • MAX_WAL_SIZE
      • Effects checkpoint(exceed maxl_wal_size or timing)
      • WAL_LEVEL = LOGICAL ; MAX_REPLICATION_SLOTS >= 1;
      • MAX_WAL_SENDERS >= 1; WAL_SENDER_TIMEOUT = 0
      • not adjustable in Aurora PostgreSQL; only Amazon RDS PostgreSQL
  • デザインガイドライン
    • Materialized Views
      • FAST REFRESH  not available
      • automatic incremental refresh NA
    • Temporary tables are dropped after every SESSION and RECREATED
    • Parameters
      • Random_page_cost = 1(4 was the default:Index Scan if you are having table scan)
      • Set on - Log_connections, log_disconnections, log_lock_waits, huge_pages
      • Shared_preload_libraries = 'pg_stat_statements, auto_explain.pgaudit'
  • AWS DMS を使ったOracleからPostgreSQLへの移行
      • SCTを利用しスキーマ移行
      • DMSのレプリケーションインスタンスを利用しデータ移行

  • AWS DMSのベストプラクティス

  • RDSとAuroraの比較
    • MySQLは5倍、PostgreSQLは3倍の高性能
    • リードレプリカ数の違い
    • Failover時間、Auroraは30秒未満
    • Storage:Auroraは10GB単位で自動拡張し、最大64TB
    • 可用性:Multi-AZ に対して、3つのAZに6つのコピー

感想

ターゲットDBとなるPostgreSQLについて、推奨されるパラメータ等が紹介されていました。また、下記ブログの内容も今回のセッションに関連して、OracleからAurora PostgreSQLへ移行するにあたり非常に役立つ内容かと思います。特にPostgreSQL周りのパラメータ設定等について理解を深める手助けになればと思います。

以上です。