Adrian Cantrill’s SAA-C02 study course, 75 minutes: ‘[DEMO] Migrating WordPress into Aurora’ parts 1 & 2
Part 1: Today I reviewed the demo for migrating our WordPress website onto a small Aurora cluster. The tutorial was two parts.
What we did in the demo was take the RDS snapshot we had created in a previous demo lesson and we migrate it to Aurora; we used an RDS snapshot to create an Aurora cluster. At the beginning of the demo we were reminded that the version we chose when provisioning an RDS instance is important, especially if we want to migrate to Aurora, or Aurora Serverless. In an earlier demo lesson we had created an RDS instance with a very specific version (MySQL 5.7.1). Choosing this version enabled easy migration to Aurora.
To reiterate, we took the RDS snapshot and used that to create an Aurora Cluster. There were a couple of interrelated goals here; to automate the process in the background and also step through it manually.
As a first step we moved to the RDS console. From here we selected the ‘snapshots’ tab and chose the snapshot containing our most recent version of the WordPress site. From here we clicked on the hyperlinked name of the snapshot and copied the snapshot ARN. The reason we needed to do this is that the lesson had a ‘one-click deployment’ which when deployed provisioned a CFN stack with all the necessary infrastructure, including a base VPC template, bootsrapped WordPress instance, and an Aurora DB (2.07.1) instance. In the screen for the one-click deployment we scrolled to the ‘DatabaseRestoreSnapshot’ section and pasted in the snapshot ARN to have that snapshot restored into the Aurora cluster. After doing this, I was instructed to click on the create button, which created the aforementioned base VPC infrastructure, a WordPress instance, and an Aurora cluster which would be populated with the data within that previously generated RDS snapshot.
While the CFN stack was creating, we were walked through the process of doing all this manually, the intention being for us to grow our comprehension by digging into the mechanics of this entire process. To start with this manual walk through we navigated back to the snapshots tab in the RDS console and checked the box next to the RDS snapshot we wanted to use. Then we clicked on the Actions dropdown and selected ‘Migrate snapshot’ from the list, which we chose to migrate to an Aurora cluster. We achieved this by selecting which DB engine to migrate to in the instance specifications console within RDS. We also picked which database engine we wanted to pick, deliberately choosing a version that was Aurora-compatible. Other options available in this screen included DB instance class, DB instance identifier, network and security specifications, including which VPC to deploy into, subnet group(s) for replica deployment, public accessibility, and an availability zone for the initial Aurora replica. We also needed to specify the VPC security group, for controlling access into the Aurora cluster, the database port, db parameter group, db cluster parameter group. Other options included encryption settings, log exports, and lastly, any maintenance settings.
After doing all this we walked through the process of manually provisioning an Aurora cluster to demonstrate the similarity between this process and the foregoing, but with many more options. Emphasis was placed on the fact that you do not specify how much storage you will use for Aurora, and that you cannot choose the type of storage: it is always high-performance SSD for Aurora.
Part 2:
Picking up from the end of part 1, we noted that there was a 30 minute lapse for the Aurora cluster to provision. This was presented as a fairly normal time lapse for a smaller database, with the added caveat that the amount of data stored in the snapshot will also affect the creation time.
From here we navigated to the databases console within the RDS console, and refreshed the screen. After doing so we were able to see the general structure of the Aurora cluster via the UI. We were able to see that the Aurora cluster is a regional construct using the Aurora-MySQL engine, and in this case it was deployed in us-east-1. This cluster also had two instances associated with it, and information about the instances was also available, there being a writer and reader instance in this case, and these were deployed into different AZ’s within the same region. It was noted that because of this deployment, the Aurora cluster can cope with the failure of any single availability zone in the region and continue operating with a brief outage.
This was followed up by a review of how Aurora clusters are differently interacted with than normal RDS. Where normal RDS has a primary instance and optionally a standby instance, and where that standby instance can’t be used for any operations, only failover, with Aurora you can provision multiple replicas, each of which can be located in the same or different AZ’s. Also, multiple replicas can be used for read and write functionality, or, as in the case at present, we have one write replica and one read replica. Unlike RDS, these additional replicas can be used to scale read capacity. The way this is achieved is through providing each cluster with a number of endpoints. The first endpoint is the cluster endpoint, which will always communicate with any instances capable of performing reads and writes. The other endpoint options are write and read endpoints, which map to their respective replica types. Also, because Aurora uses cluster shared storage, all the replicas will communicate with the same storage. So if there is a need to provision more instances or perform a failover operation, they tend to be much quicker than using normal RDS, because they are all using the same shared storage.
Another option is to create custom endpoint which point at specific subsets of instances within the cluster.
After this we took a snapshot of the writer instance for use in an upcoming lesson on serverless architecture. After this we looked at using local media storage for persistent storage. We learned why this was necessary by taking the public ip for the EC2 instance that was created from the snapshot restore and opening the blog in a new tab. Everything loaded normally except that the cat pictures were missing. It was explained that when we terminated our last session, we terminated the local EC2 instance from that session, and the images we need were stored on that EC2 instance, so even though we have all the DB metadata, the images themselves were locally hosted, so they were destroyed when the session was terminated. The point here was to understand that restoring a snapshot creates a new EC2 instance, and for this reason we need persistent storage for anything that may have been residing on a created EC2 instance.
CloudMastermind 