Now that all databases have been migrated to Aurora, it’s time to update the DNS information so the application server can connect to the related Aurora database server. Both apps are using a DNS entry as a connection hostname. In a real-world application migration, once you have completed all of your testing and are ready to fully transition your databases to Aurora, you should perform the shutdown of the source servers and update the DNS records properly to reflect the new database servers running in Aurora.
Once connected to the bastion host, open putty.
Connect to the server wordpress-db. The username and password are in your Event Engine dashboard. Or, if you are running this lab in your own AWS account, the username is user and the password will be the same that you put as a parameter when you launched the CloudFormation stack.
Now, we will update the database DNS record and point it to the Aurora database. First, check the current database DNS record running following command from the putty terminal:
nslookup wordpress-db
Let’s create a variable (ADDR) using the RDS endpoint that you wrote down in the first step of this page “MySQL (WordPress) step 3”.
ADDR="<REPLACE THIS WITH WORDPRESS ENDPOINT THAT YOU WROTE DOWN IN THE FIRST STEP OF THIS PAGE>"
Then, run the following commands to update the DNS record:
HOST="wordpress-db.onpremsim.env"
sudo touch /tmp/nsupdate.txt
sudo chmod 666 /tmp/nsupdate.txt
echo "server dns.onpremsim.env" > /tmp/nsupdate.txt
echo "update delete $HOST A" >> /tmp/nsupdate.txt
echo "update delete $HOST PTR" >> /tmp/nsupdate.txt
echo "update add $HOST 86400 CNAME $ADDR." >> /tmp/nsupdate.txt
echo "send" >> /tmp/nsupdate.txt
sudo nsupdate /tmp/nsupdate.txt
HINT: Use a text editor to arrange the commands before past it into the putty
Verify the DNS name resolution again and check if it was updated to a CNAME pointing to your Aurora database (compare the output with the previous step):
nslookup wordpress-db
Shutdown the source database server as we no longer need it:
sudo shutdown -h now
From the BASTION host, test the application using Chrome web browser:
Application | Test URL |
---|---|
Wordpress | http://wordpress-web.onpremsim.env/ |
This is the expected screen if the migration was successful:
This test should be executed from INSIDE the Bastion host.
From the BASTION host, open putty.
Connect to the server ofbiz-db. The username and password are in your Event Engine dashboard. Or, if you are running this lab in your own AWS account, the username is user and the password will be the same that you put as a parameter when you launched the CloudFormation stack.
Now, we will update the database DNS record and point it to the new Aurora database. First, check the current database DNS record running following command from the putty terminal:
nslookup ofbiz-db
Let’s create a variable (ADDR) using the RDS endpoint that you wrote down in the second step of this page (PostgreSQL (OFBiz) step 3).
ADDR="<REPLACE THIS WITH OFBIZ ENDPOINT THAT YOU WROTE DOWN IN THE FIRST STEP OF THIS PAGE>"
Then, run the following commands to update the DNS record:
HOST="ofbiz-db.onpremsim.env"
sudo touch /tmp/nsupdate.txt
sudo chmod 666 /tmp/nsupdate.txt
echo "server dns.onpremsim.env" > /tmp/nsupdate.txt
echo "update delete $HOST A" >> /tmp/nsupdate.txt
echo "update delete $HOST PTR" >> /tmp/nsupdate.txt
echo "update add $HOST 86400 CNAME $ADDR." >> /tmp/nsupdate.txt
echo "send" >> /tmp/nsupdate.txt
sudo nsupdate /tmp/nsupdate.txt
HINT: Use a text editor to arrange the commands before past it into the putty
Verify the DNS name resolution again and check if it was updated to a CNAME pointing to your Aurora database (compare the output with the previous step):
nslookup ofbiz-db
Shutdown the source database server as we no longer need it:
sudo shutdown -h now
From the BASTION host, test the application using Chrome web browser:
Application | Test URL | App username | App password |
---|---|---|---|
OFBiz ERP | https://ofbiz-web.onpremsim.env:8443/accounting | admin | ofbiz |
This is the expected screen if the migration was successful:
All the commands listed on this guide should be executed from INSIDE the Bastion host.