One very strong case for cloud computing is that it can satisfy applications with seasonal traffic patterns. One way to test the advantages of the cloud is through a hybrid approach.
Cloud infrastructure can be built completely through scripts. You can spinup specific AMIs or machine images, automatically install and update packages, install your credentials, startup services, and you’re running.
All of these steps can be performed in advance of your need at little cost. Simply build and test. When you’re finished, shutdown those instances. What you walk away with is scripts. What do we mean?
The power here is that you carry zero costs for that burst capacity until you need it. You’ve already build the automation scripts, and have them in place. When your capacity planning warrants it, spinup additional compute power, and watch your internet application scale horizontally. Once your busy season is over, scale back and disable your usage until you need it again.
Deploying in the Amazon cloud is touted as a great way to achieve high scalability while paying only for the computing power you use. How do you get the best scalability from the technology? Continue reading “3 Ways to Boost Cloud Scalability”
Database replication is a service for shipping changes to your database, off to a copy housed on another server, potentially even in another data center.
Each change to the records of information in your database or groups of them are organized into transactions. These each get unique identifiers or change numbers. Those groupings of changes are logged to transaction logs which are then moved across to the sibling database server, and applied there.
Oracle offers this facility in the form of Standby Database aka Dataguard. Although it can be messy to setup, it is fairly bulletproof. If you don’t receive any errors in your logfiles, you can rest assured that the data on your main or master database server looks exactly the same as what’s on your secondary server. With MySQL the situation can be a bit more complicated. MySQL replication was built based on statements, not changed data. So those same statements or instructions (SQL statements of DML & DDL) get rerun on the secondary database server. Some of the problems associated with this are:
- MySQL standby transactions may execute at different times than master
- Serialization is important to maintain order. Transactions need to get applied in the same order as on the primary. However all tables & storage engines are not necessarily transactional in MySQL. This can cause troubles, and potentially break replication on the slave side.
- MySQL replication can fail silently, that is data can drift out of sync with the master without your knowing.
Caveats aside, MySQL replication is powerful, and quite fast. With the right caution, and correct tools, it can be as robust and reliable as Oracle’s own standby database technology.
- Use checksum tools like Maatkit to verify & compare tables on primary & secondary servers
- Use rigorous monitoring to watch error logs, and checksum logs hourly if necessary.
- Use Maatkit sync tool to resync tables if they get out of whack.
- Be especially vigilant if you’re taking backups off the secondary server
Replication can also be a powerful high availability tool in your arsenal. Setup as a master-master cluster, you can keep your application pointed to the “active” side or role while performing blocking operations on the inactive database server. Since master-master cluster also known as circular replication applies changes to both databases, you’ll need to stop replication during the blocking operation. Once it is completed on the inactive side, redirect the webservers & application to the database where you completed the operation, then reenable replication and watch the databases catch up with each other!
Quora discussions – What is database replication?