February 26, 2010 5:35 p.m.
Now that the initial data migration has been completed, we can proceed with testing and the final push of data. The following parts are not that complicated and will actually use a lot of the same steps that have already been explained.
Before testing can begin, there are a few changes needed to configure the site on the new server to reflect the new environment. First, I usually change the config file that contains the database connection information to reflect the host and login information for the new database. Depending on your programming environment, these options may be listed in it's own file or like in my case, directly in the Apache config file.
While editing the apache config file for my database changes, I will also make a couple of other changes. This being a new server, I need to edit my VirtualHost directive to reflect the new IP address of this server. If you use name based virtual hosts instead of ip based, then this will not be necessary. Then I also add some temporary ServerAlias name to the config that I can use for testing the new site before the final data push. Since I have DNS control, I use a subdomain like newserver.domain.com or something similar. Then the last thing I do before testing is to add a new record to DNS to point the temporary subdomain to the new server IP address.
Testing is pretty standard and straight forward. I just open my browser and go to the new subdomain. Navigating around most if not all of the site is very important to make sure that nothing was broken during the rsync. Also to make sure that any software on the new server is compatible with the legacy code.
Once testing is complete, I move onto the final data push and making the site on the new server live. In these steps timing is crucial. So, I usually have several things open and going on at the same time. Normally I will have three terminals open and connected to the old servers. One for the old database server and the other two connected to the old web server.
In one of the terminals connected to the old web server I push the site one last time to make sure that nothing has changed since my last push. This is done with the following command just like in the part 1 post.
rsync -progvult site_directory -e ssh new_server_name_or_ip:/full/path/to/new/site/dir/
(you must include a trailing slash at the end of your path)
In the second terminal connected to the old web server I edit the apache config file to change my database connection settings to reflect the new database server. If your database options are not in the apache config, you will want to wait and do this once the database has been pushed for the last time. In my case, I can edit the settings and just wait to restart apache once I've pushed the database.
In the terminal connected to the old database server I push the database again to make sure nothing has changed since my last push. Typically I do this a couple of times in the event that the site has high traffic and data is inserted regularly. This can be done with the same command like in the part 1 post as well. Once I see a lull in the database sync, I just back to the old web server terminal and restart apache really quick.
rsync -progvult db_directory -e ssh new_server_name_or_ip:/var/lib/mysql/
(once again, trailing slashes are important)
Now you have the site on the old server using the new database for selecting and storing data. At this point, the only thing that will be out of sync are the apache log files. I typically don't mind and will only be a problem during DNS propagation.
The last thing needed is to change DNS to reflect the IP address of the new server and wait for propagation. Once that is complete all traffic should be going to the new server within the next 24-72 hours. I usually wait three to five days and then shut down or archive the site on the old server.