Disaster Recovery (DR) is the process an organization uses to recover access to their software, data, and/or hardware that are needed to resume the performance of normal, critical business functions after the event of either a natural disaster or a disaster caused by humans. In the event of a disaster, the continued operations of your company depend on the ability to replicate your IT systems and data. The disaster recovery plan stipulates how a company will prepare for a disaster, what the company’s response will be and what steps it will take to ensure that operations can be restored.
When an unforeseen event takes place and causes day-to-day operations to come to a halt, a company will need to recover as quickly as possible to ensure you will continue providing services to clients and customers. A disaster recovery plan would place your production servers in a top tier data centre with no single point of failure on the power and network connections.
Why Cloud For DR?
Having DR sites in the Cloud reduces the need for data center space, IT infrastructure and IT resources, which leads to significant cost reductions, enabling smaller companies to deploy disaster recovery options that were previously only found in larger enterprises. There’s no need to invest in more hardware or allocate additional IT personnel to bother with extra maintenance tasks. Instead, you have convenient access to a supremely elastic infrastructure that scales seamlessly based on your resource demands.
When connected to the Cloud, you are not hinged to a single location, data center or network. So even if one building loses power after a vicious storm, your operation can stay online and continue to roll.
Since in Cloud the virtual server is hardware independent, the operating system, applications, patches and data can be safely and accurately transferred from one data centre to a second data centre without the burden of reloading each component of the server. This can dramatically reduce recovery times compared to conventional (non-virtualized) disaster recovery approaches where servers need to be loaded with the OS and application software and patched to the last configuration used in production before the data can be restored.
What is DMS?
AWS Database Migration Service is a service provided by AWS which helps you to migrate your databases to AWS quickly and securely. The source database remains fully operational during the migration, minimizing downtime to applications that rely on the database. The AWS Database Migration Service can migrate your data to and from most widely used commercial and open-source databases. The service aims to reduce the duration of database transfers, which can take months otherwise. AWS DMS can handle homogenous migrations, such as Oracle to Oracle, as well as heterogeneous migrations, such as Oracle to MySQL. One of the endpoints must always be in AWS; the other can be on-premises, running on an EC2 instance, or running on an RDS database instance.
The AWS Database Migration Service works by setting up and then managing a replication instance on AWS. This instance unloads data from the source database and loads it into the destination database and can be used for a one-time migration followed by on-going replication to support a migration that entails minimal downtime.
AWS Database Migration Service is simple to use. There is no need to install any drivers or applications, and it does not require changes to the source database. Once the migration has started, DMS manages all the complexities of the migration process including automatically replicating data changes that occur in the source database during the migration process.
Prerequisites for using DMS:
- On-premises Database user should have full privilege over the Database.
- One of the endpoints must always be in AWS.
- Firewall should be disabled, or port used by database should be opened for DMS to communicate.
- Understand the features and limitation of AWS DMS. For more information: http://docs.aws.amazon.com/dms/latest/userguide/Welcome.html
- Should understand Amazon RDS and the Database used for migration.
- Should have Required Privileges over AWS account where DMS is used.
- For DMS replication, the proper IAM permissions, Security Group rules, on-premise database access, and VPC access for your network should be confirmed.
- Understand the supported data type conversion options for Oracle and PostgreSQL.
Steps for implementation of DMS:
- Before Creating DMS, following things should be implemented:
- Required Infra set up should already be done in AWS (For example: Ec2 and RDS)
- Make sure you have set up proper infrastructure on AWS used as Target instance. RDS needs to be created where the migration of your database will take place.
- If you are doing migration over the internet, then your RDS instance should be created in Public.
- RDS parameter group should be changed as:
- If you are migrating MySQL Database to RDS: Run the command,
call mysql.rds_set_configuration (‘binlog retention hours’, 24);
- If you are using MySQL as Source update my.conf file:
- server_id: set to 1 or greater.
- log-bin: set the path
- binlog_format: ROW
- expire_logs_days: set to 1 or greater.
- binlog_checksum: NONE
- binlog_row_image: FULL
For more information see, https://docs.aws.amazon.com/dms/latest/userguide/CHAP_Source.MySQL.html
Creating Replication Instance:
- Go to AWS DMS service and click on replication Instance.
- Click on create Replication instance.
- Give the name and description for the replication Instance.
- Choose instance class and Engine version to be used.
- Choose the VPC to be used. Make sure the VPC you are using should be the same where your RDS is launched.
- Choose multi-Az as No and check publicly accessible.
- Choose the replication Subnet group and VPC security group as needed.
- leave all the field as it is and click on create Replication instance.
- Now, your replication instance has been created.
- Go to AWS DMS service and Click on Endpoints.
- Click on create Endpoints.
- Choose Endpoints type as Source. If your Source is RDS then click on RDS instance or leave as it is.
- Give the unique name for Endpoint Identifier and choose the source database (MySQL, MsSQL, etc.).
- Provide the Server name, this could be the IP of the on-premises server where your Database is or endpoints of the RDS.
- Provide the port number in which your database is listening and give username and Password to access your database by DMS.
- Leave the Advanced field as it is and go to Test endpoint connection (optional).
(Test endpoint connection helps to know if AWS DMS can communicate with your database or not.)
- Provide VPC and Replication instance name to test the connection. If everything you provided is correct the test connection will be successful.
- Click on create endpoints.
- Follow same steps to configure the Target as well Giving target Server name, Port, Username, Password and test the connection for this.
- Go to AWS DMS service and click on task. Task is the process with the help of which we migrate our on-premise database to AWS Cloud or Vice-Versa.
- Give the task name as you want.
- Choose Replication instance name for the drop down.
- Choose Source and Target Endpoint you have created before.
- Choose the migration method you want to use. You can choose to have just the existing data migrated to the target database or have ongoing changes sent to the target database in addition to the migrated data.
- Check mark Start task on create, this will start your task as soon as task is created.
- In the task setting choose the option as per your need. Enable logging helps you to find out the any error occurred in migration of the database.
- In Table mappings field, Choose the Schema name, table name looks like (you can keep this as default) and leave all the field as it is. Click on Add selections Rule. You must have one selection rule in a task.
- Click on create Task.
When the task gets started the database from on-premises will start migrating to AWS Cloud (i.e on RDS).