PPCD_And_AmazonRDS

© Copyright EnterpriseDB Corporation, 2015. All Rights Reserved. 1

Migration Journey: Amazon RDS to PPCD

• Vibhor Kumar | 2015.05.19


Migration JourneyAmazon RDS to PPCD

• Vibhor Kumar | 2015.05.19


• A distributed relational database service.

• Running as a web service "in the cloud”− First released on 22 October 2009 supporting MySQL

databases− Oracle Database in June 2011 − Microsoft SQL Server in May 2012 − PostgreSQL in November 2013

About Amazon RDS


• Limited Storage Capacity – 3 TB− RDS size limit reached

• Slow Performance− Concurrency Issues− Latency

• Cost

• Less control over System.

Business Challenges in RDS


• Easy, fast start-up in minutes

• Self-healing clusters• Scheduled backups• Automatic failover

• Elastic storageAdds disk space when needed

• Elastic scale outClusters scale automatically

• Easy to use monitoring

EASY

• Set your own scale-out and back-up parameters• Access to set your own tuning configurations

MAXIMUM CONTROL

• Run PostgreSQL or Postgres Plus Advanced Server• Same DB in Cloud as in data center--Portability between

environments

• AWS, OpenStack, or bare metal environments

PORTABILITY

© 2014 EnterpriseDB Corporation. All rights reserved. 5

CLOUD DATABASE

POSTGRES

PLUS Enterprise Control

& Portability


DATABASE CLUSTER

Master Database

Writes Reads

StreamingReplication

Master ReplicasMaster ReplicasMaster Replicas

AUTOMATICALLY CREATED

Connection Pooler & Load Balancer

Postgres Plus Cloud Database

Cluster ManagerAuto-provisioning, Health Check, Auto: Failover, Scaling, Backup

GUI Cloud Console

Admin Appor Terminal

Cloud ResourcesNetwork, Elastic IP, Elastic Storage, VMs, Security, Hardware

Client Apps/Users

Auto Elastic

Scale-Out


Postgres Plus Cloud Database

ssh

1

2

3

47

6

5

8

1 Scale replicas up / down2 Clone cluster3 Upgrade Postgres version4 Scale server class5 Server DNS / Port6 Failover modes7 User selectable scaling thresholds8 DB Configuration, monitors, log


• Activities performed by customer:− Initially started with

pg_dump and pg_restore for data movement.

− Tried with Bucardo Replication from Amazon RDS to PPCD− Bucardo Crashed

Initial engagement

• Initial expectations with sales:− Review their strategies− Review the replication− Work with them for Slony

replication review

Resulted


• Limitation learned from Amazon RDS team

• Slony replication limitation.

• Streaming Replication limitation.

Key Findings


• Proper plan required:− Understanding of Business Constraints (Maintenance

Windows, Downtime window etc).− Information about objects− Active Data/objects information− Inactive data/objects information− Business Critical Objects.

Planning


• Factors considered − Active tables:

− Customer facing tables (direct access from application)− Table Sizes− Maintenance Windows

− Inactive tables:− Archived Tables.− Internal reporting tables.

• Solution recommended:− xDB replication for :

− Large Business Critical objects.− Parallel pg_dump and pg_restore for small active tables.− Others can be done during Migration plan implementations

Migration plan


• EDB tool for replication− Has CLI options

• customer requirements− Replication Monitoring.− Data Validation.

xDB replication and Customer requirements


• xDB limitations− No command line monitoring option.− Prepared statements− No default xDB connection monitoring.− Architecture issues.− NaN issue

xDB replication


• Issue: Monitoring Replication.

• Solution:− Define scripts based on xDB Meta tables

− xdb_print_last_replog.sh− xdb_row_lag.sh

xDB limitation and Solution


• Issue: prepared statements− Generic plan.

• Solution. − Update catalog xDB catalog table:

− erep_pub_database.url_options=prepareThreshold=0



• Issue: xDB connections Monitoring

• Solution. − Update catalog xDB catalog table:

− erep_pub_database.url_options=‘ApplicationName=xdb&prepareThreshold=0’

- pg_stat_activity.application_name = ‘xdb’, shows connections



• Issue: Architecture issue− Source connection lost before updating replicated

transactions:− Duplicate key issue

• Solution. − xDB synchronization script:

− xdb_synch_subscription.sh− Before perfoming sync operation, updates

erep_publication_subscriptions=‘O’



• Issue: NaN (Not a Number issue)− xDB doesn’t NaN value properly

• Solution. − Modified shadow table to have varchar data type for specific

shadow column:− Created a trigger on shadow table, so that NaN value stored in

shadow table should have ‘NaN’



• Customers Trigger on Replicated tables− Resulted in Data loss

• Solution :− Ask when they have created trigger

− Verifed with Customer.− Verified in postgresql log (proper log_statements)− Made transactions pending which was created after Trigger in

xDB catalog rrep_txset.status = ‘P’

Customer’s Mistake


• After fixing all issues of xDB, perfored− Final sync with xDB commands

• Performed parallel dump and restore on target database.

• Application was pointed to

Project Wrap up


• Amazon RDS has limitations

• Online Migration from Amazon RDS to PPCD is possible!

• Normal Solution for Migration will not work.

• Make Proper plan by Interviewing Customer.

• Be ready with before and after Migration scripts according to Plan.

• Be ready for surprises and validate setup before Migration activity starts.

• Have deep knowledge of tools used for Migration.

Lessons Learned


Documents

PPCD_And_AmazonRDS