![]() ![]() To achieve the least user impact, especially to avoid potential business loss, we set the goal of zero read downtime, and minimizing write downtime as much as possible.Īccording to AWS doc, there are two ways to migrate from RDS to Aurora: We have to first upgrade to 10.x, then 11.8. This is how we found out that it is impossible to upgrade 9.6.11 directly to 11.8, no matter in RDS or Aurora. ![]() To check available upgrade target versions for Aurora PostgreSQL from a given version, use this: $ aws rds describe-db-engine-versions \ -engine aurora-postgresql \ -engine-version \ -query 'DBEngineVersions.ValidUpgradeTarget' With AWS CLI, the following command checks available engine versions of Aurora PostgreSQL in a particular AWS region ( source): $ aws rds describe-db-engine-versions -engine aurora-postgresql -query '*.' -output text -region Īlso with AWS CLI, the following commands check available upgrade target versions from a given PostgreSQL version in a given AWS region ( source):įirst, export the AWS region and that region’s RDS endpoint as the terminal tool’s environment variables: $ export REGION= $ export ENDPOINT= Then, to check available upgrade target versions for RDS PostgreSQL from a given version, use this: $ aws rds describe-db-engine-versions \ -engine postgres \ -region $REGION \ -endpoint $ENDPOINT \ -output text \ -query '*.ValidUpgradeTarget.' \ -engine-version Although the lowest Aurora compatible PostgreSQL is 9.6.8 ( source), Aurora Global Database is only compatible with PostgreSQL 10.11, 10.12, and 11.7 up ( source).įor some more buffer time before the next major version upgrade, we chose the newest Aurora compatible PostgreSQL version in our target AWS regions, 11.8, as the upgrade target version. The only problem is, our PostgreSQL database was still on version 9.6.11. Once we have an Aurora database cluster, adding the first secondary AWS region will automatically turn it into an Aurora Global Database. Geographically it is easy to group the seven (and more to come in the future) overseas markets into less than five AWS regions. Plus the scalability and availability improvement (think about cross-region failover), migrating to Aurora Global Database is a no-brainer. As for the number of replicas, it will allow us 15 replicas in the primary region and 16 in each secondary region (source). It supports cross-region read-only replicas in up to five AWS regions (secondary regions as named in AWS docs, as opposed to the primary region where the master database instance resides,) with less than one second cross-region replication latency. minimize the impact to the live system.įor the first requirement, AWS Aurora Global Database is a low-hanging fruit solution.The daily traffic could amount to 20 million accesses, any downtime has impact on real users, any read downtime could result in business loss. The system has been running on production for nearly 2.5 years, now serving eight client systems from seven countries. With the fourth overseas market’s rollout date approaching, the fifth, sixth and the seventh overseas market also had their rollout plan laid out. ( source ) How and How NotĪn architectural level change to address the database replica limit is unavoidable. RDS only supports up to five replicas, no matter same- or cross-region. The fourth is supposed to come early next year, when we hit a wall: In each overseas market, one replica was created to serve that market’s API read traffic.Īs time went by, the system has been rolled out to three overseas markets. In the main market’s AWS region, the master instance serves write traffic coming from importing upstream data and admin applications, one replica serves in-region API read traffic, while another replica serves all regions’ batch read traffic. Since Aurora PostgreSQL didn’t came into being until right before the project start, the database solution was designed to use RDS PostgreSQL with same- and cross-region replicas. The database choice was PostgreSQL and the whole infrastructure is on AWS. ![]() In the summer of 2017, we started to design and build a system that imports and administrates business data in the main business region, then ships the data as a suite of microservice API endpoints and batch file feeds to the global markets. This is a story about rescuing a not-so-old system from the legacy architecture design which no longer suits its global requirements. Migrate PostgreSQL on AWS from RDS to Aurora ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |