FAQ

FAQs - RDS AlwaysOn/Geo-Replicate

  1. How does RDS SQL AlwaysOn/Geo-Replicate compare to RDS Multi-AZ and MS SQL Server native AlwaysOn Availability Groups?
  2. Does RDS SQL AlwaysOn support RDS SQL Server Web Edition ?  Does it also allow mixing of On-premise MS SQL Server, EC2 SQL Server and RDS? Also does it allow geo-replication (cross-region) from RDS and EC2 SQL Server Standard and Enterprise to Web Edition? Do both SQL servers need to be same type/size?
  3. Does RDS SQL AlwaysOn support InterCloud replications such as AWS RDS to Azure SQL and Google Cloud?
  4. Amazon’s RDS SQL Multi-AZ seems like an attractive value proposition, but it is rather expensive and the mirrored MS SQL Server is not even a read-replica, it cannot be used for reporting. Besides, the only option to create the MS SQL Server replica is to another zone within the region. Can CloudBasic’s RDS SQL AlwaysOn/Geo-Replicate be used instead of RDS Multi-AZ? What is the estimated replication lag?
  5. Our primary systems are located in AWS US-East Virginia, but we expect heavy read-traffic from Europe and Asia (mobile apps hitting the closest APIs in Frankfurt and Tokyo). Can we use RDS SQL AlwaysOn/Geo-Replicate to create more than one geo read-replicas in Europe and Asia for each database on our primary RDS SQL Servers in US Virginia?
  6. How do I get started with RDS SQL AlwaysOn/Geo-Replication Service?
  7. What MS SQL Server sources and targets does CloudBasic RDS AlwaysOn replication solution support?
  8. Why should I use CloudBasic RDS SQL AlwaysOn Service instead of my own self-managed replication solution?
  9. Can I monitor the progress of a database replication task?
  10. How do I integrate RDS SQL AlwaysOn with other applications?
  11. Can I replicate data from encrypted data sources?
  12. Can CloudBasic RDS SQL AlwaysOn/Geo-Replicate be used to replicate MS SQL Server RDS and EC2 SQL Server across different AWS accounts? I see that it handles cross-region replication, but does it do cross-AWS-accounts replication? Our DR requirements state that all DR artifacts must be stored in completely separate AWS accounts. This ensures that an account level security breach would not affect business continuity. Does your tool replicate across AWS accounts?
  13. Can RDS SQL AlwaysOn can have replication setup from multiple different instances of RDS into one instance of RDS in a different region?
  14. Can CloudBasic RDS SQL AlwayOn Replication Service migrate databases for me?
  15. Are database schema changes replicated?
  16. Would we need to do anything to our existing RDS SQL server database to make this solution work?
  17. What is the replication impact on the primary source MS SQL Server?
  18. How would a fail-over work? Would we manually change our application tier to point to the new Primary?
  19. How far behind is the synchronization at any point in time? Looking at your testing it seems like it would be < 30 seconds in most scenarios.
  20. Some versions of CloudBasic Multi-AR come with pre-installed MS SQL Server Standard or Web Edition. Can I extend the default data storage?
  21. How would we go back to the previous primary MS SQL Server once an outage is resolved?
  22. Can notifications be setup to alert us if there are any replication delays or outages?
  23. Will replications resume/catch up in case of any connectivity issues or if source or replica MS SQL Servers are taken down for maintenance? What is the allowed downtime?
  24. Does this product feature command line/API scheduling functionality?

Top of Page

Q 1: How does RDS SQL AlwaysOn/Geo-Replicate compare to RDS Multi-AZ and MS SQL Server native AlwaysOn Availability Groups?

A: Unlike with AWS RDS Multi-AZ for MS SQL Server the replicas are actually accessible and can be used for reporting. Moreover the replicas can be located in another region, or even in another cloud (i.e. Azure, Google Cloud) or On-Premise.

Unlike both RDS and MS SQL Server native AlwaysOn Availability Groups, replication of even MS SQL Server Web Edition is supported. Using MS SQL Server Web Edition instead of MS SQL Server Standard and Enterprise results to substantial savings. For more information, and a sample scenario, refer to the AWS RDS Multi-AZ (MS SQL Server) vs. RDS AlwaysOn/Geo-Replicate price comparison table: http://cloudbasic.net/aws/rds/alwayson/aws-multi-az-vs-cloudbasic-multi-az-ar/

And unlike MS SQL Server’s native AlwaysOn Availability Groups, there is no requirement for Active Directory or Witness servers. And yet, replication of all RDS and MS SQL Server versions, including Web Edition, is supported.

Top of Page

Q 2: Does RDS SQL AlwaysOn support RDS SQL Server Web Edition? Does it also allow mixing of On-premise MS SQL Server, EC2 SQL Server and RDS? Also does it allow geo-replication (cross-region) from RDS and EC2 SQL Server Standard and Enterprise to Web Edition? Do both MS SQL servers need to be same type/size?

A: Yes, this product supports RDS SQL Server Web Edition. It supports all RDS EC2 and MS SQL Server versions, and allows replication between any RDS type and EC2 SQL Server version, from on-premise MS SQL Server to AWS RDS and EC2 SQL Server. It can be used for any type of Geo-replication scenario. Since this product replicates asynchronously, it allows the replica RDS or EC2 SQL Server to be hosted on a smaller and less expensive instance EC2 or RDS SQL Server.

Top of Page

Q 3: Does RDS SQL AlwaysOn support InterCloud replications such as AWS RDS to Azure SQL and Google Cloud?

A: Yes, AWS RDS to Azure SQL is supported. The initial replication might be a little challenging depending on the database size. However the continuous replication is supposed to work smoothly for most use case and data change volumes. You can see a benchmark comparing AWS RDS Cross-region replication against AWS RDS to Azure SQL benchmark here: http://cloudbasic.net/aws/rds/alwayson/benchmark/

Top of Page

Q 4: Amazon’s RDS SQL Multi-AZ seems like an attractive value proposition, but it is rather expensive and the mirrored MS SQL Server is not even a read-replica, it cannot be used for reporting. Besides, the only option to create the MS SQL Server replica is to another zone within the region. Can CloudBasic’s RDS SQL AlwaysOn/Geo-Replicate be used instead of RDS Multi-AZ? What is the estimated replication lag?

A: Yes, using CloudBasic's RDS SQL AlwaysOn instead of RDS Multi-AZ is a common use case. It is used in various scenarios, including when the system architecture requires reporting to not run against the primary RDS, for data offloading. Also, since RDS SQL AlwaysOn Multi-AZ capabilities go beyond the boundaries of the AWS region (Multi-AR), it can be used for data locality. RDS AlwaysOn delivers good performance even in cross-region scenarios (AWS Cross-Region & AWS-to-Azure/GoogleCloud): http://cloudbasic.net/aws/rds/alwayson/benchmark/

Sample configuration:

RDS Source: r3.XLarge, MS SQL Server EE w/ Encryption and Multi-Zone Mirroring
RDS Destination: m3.Large, MS SQL Server 2012 Web Edition
RDS Source Location: US-East-1 (Virginia)
RDS Destination Location: US-West-1 (California)

Top of Page

Q 5:  Our primary systems are located in AWS US-East Virginia, but we expect heavy read-traffic from Europe and Asia (mobile apps hitting the closest APIs in Frankfurt and Tokyo). Can we use RDS SQL AlwaysOn/Geo-Replicate to create more than one geo read-replicas in Europe and Asia for each database on our primary RDS SQL Servers in US Virginia?

A: Yes, this is a common use case. The replication is handled asynchronously; replication over long distance internet connections to remote region is possible.

Top of Page

Q 6: How do I get started with RDS SQL AlwaysOn/Geo-Replication Service?

A: Getting started with RDS SQL AlwaysOn/Geo-Replication is quick and simple. Most data replication tasks can be set up in less than 10 minutes. There is no requirement for Active Directory or Witness servers.

Once you sign up for the service on http://cloudbasic.net/aws/rds/alwayson/, you will receive an AMI ID and an activation key over email. Locate the AMI ID in the list of Community AMIs and launch as an EC2 server within or outside of your VPC. Once the instance is running, and port 80 opened in the security group, connect to it by pointing a browser to the public DNS root URL (or IP) at default www port 80. Activate the server with the provided activation key. Login with user: admin, initial temporary password: {EC2 Instance ID}. Upon successful login, you will land on the wizard page, which will allow you to initiate RDS/SQL Server replication in various scenarios, in just a few clicks

Top of Page

Q 7. What MS SQL Server sources and targets does CloudBasic RDS AlwaysOn replication solution support?

A: All RDS and MS SQL Server versions, including Web Edition (2008 and above) are supported. Replication between any two MS SQL Servers versions is supported. Replication from On-Premise to AWS RDS or EC2 SQL Server, from i.e. 2008 to 20016, from Standard/Enterprise to Web Edition, from AWS RDS or EC2 SQL Server to On-premise, from AWS RDS to SQL Azure, MS SQL Server on Google Cloud, Oracle Public Cloud or IBM Cloud are all supported.

Top of Page

Q 8: Why should I use CloudBasic RDS SQL AlwaysOn Service instead of my own self-managed replication solution?

A: CloudBasic RDS SQL AlwaysOn is very easy to use. It is a lightweight high-performance solution that has been designed for AWS. It has been tested by some of the largest corporations in America. It took CloudBasic’s senior engineers years to develop it and make it capable of delivering superior performance. Check out the benchmarks: http://cloudbasic.net/aws/rds/alwayson/benchmark

Top of Page

Q 9. Can I monitor the progress of a database replication task?

A: Yes. CloudBasic RDS SQL AlwaysOn has a variety of metrics displayed in Replication Runtime Console. It provides an end-to-end view of the data replication process, including diagnostic for each point in the replication pipeline.

Top of Page

Q 10. How do I integrate RDS SQL AlwaysOn with other applications?

A: RDS SQL AlwaysOn provides a provisioning API that allows creating a replication task directly from your development environment, or scripting their creation at scheduled times during the day. The service API and CLI allows developers and database administrators to automate the creation, restart, management and termination of replication tasks.

Top of Page

Q 11. Can I replicate data from encrypted data sources?

A: Yes, CloudBasic RDS SQL AlwaysOn can read and write from and to encrypted RDS databases. It will be able to extract decrypted data from such sources and replicate it to the target. The same applies to storage-level encryption. As long as RDS AlwaysOn has the correct credentials to the database source, it will be able to connect to the source and propagate data (in decrypted form) to the target. We recommend using encryption-at-rest on the target and protect data in transit using SSL to maintain the confidentiality of your information. If you use application-level encryption, the data will be transmitted through replication service, in encrypted format, and then inserted into the target database.

Top of Page

Q 12: Can CloudBasic RDS SQL AlwaysOn/Geo-Replicate be used to replicate MS SQL Server RDS and EC2 SQL Server across different AWS accounts?  I see that it handles cross-region replication, but does it do cross-AWS-accounts replication? Our DR requirements state that all DR artifacts must be stored in completely separate AWS accounts.  This ensures that an account level security breach would not affect business continuity. Does your tool replicate across AWS accounts?

A: Yes, CloudBasic can replicate across AWS accounts. All it needs is the default port 1433 opened in the firewalls on both sides.

Top of Page

Q 13: Can RDS SQL AlwaysOn replicate from multiple different instances of RDS into one instance of RDS in a different region?

A: Yes, RDS SQL AlwaysOn can support your replication scenario. You have to launch the CloudBasic server at the region/zone where the destination RDS is located. This is the recommended deployment setup for most cases.

Top of Page

Q 14. Can CloudBasic RDS SQL AlwayOn Replication Service migrate databases for me?

A: Yes. You can run a continuous replication of your database (from On-Premise to AWS, between AWS regions; or between i.e. AWS and Azure or AWS and Google Cloud) just if you were to configure the destination databases to be your read-replicas for DR or reporting. You can cut-over by terminating the continuous copy process whenever ready. Once time migration without setting up of change tracking is also an option.

Top of Page

Q 15. Are database schema changes replicated ?

A: Yes, database schema changes are replicated to the replica databases. New tables, stored procedures, constrains, FKs etc; new columns, altered columns changes are all replicated. There are only 2 exception cases (ambiguous nature) in which changes need to be synced manually: renamed column & dropped column. Alternatively for those 2 cases, the respective table at the replica can be dropped which will trigger the table to be recreated (along with all related objects) and re-seeded.

Also note that by design, dropped tables are not removed in the replica database. The DBA is responsible to drop the table on the replica database Reason: 1 - in DR scenarios, if a table is dropped by mistake, the replica MS SQL server can be still promoted to primary. 2- in Reporting scenarios, this will prevent immediate failures in reporting applications which are not updated yet.

Top of Page

Q 16. Would we need to do anything to our existing RDS SQL server database to make this solution work?

A: The only main requirement is all tables tracked for changes to have Primary Keys. Learn more about the prerequisites at http://cloudbasic.net/documentation/prerequisites/.

Top of Page

Q 17. What is the replication impact on the primary source MS SQL Server?

A: It is a low intrusion solution. As an example, we have cases where customers create up to 6-8 read-replicas in same or different regions from same primary RDS (http://cloudbasic.net/case-studies/affinity-protection/, http://cloudbasic.net/case-studies/sports/). Creation of each replica is a separate process against the primary MS SQL Server.

For replication processes involving databases with a large number of tables and heavy volume of changes, there are advanced configuration settings, allowing setting up a limit on how many tables should be handled in parallel, to further minimize the impact on source.

Top of Page

Q 18. How would a fail-over work? Would we manually change our application tier to point to the new Primary?

A: Depending on whether your replica is located in the same region or another region:

  • If your replica MS SQL Server is located in same region, you would point your applications to the EC2 server instance. You can also configure your applications to access your primary RDS via Route 53 (an AWS service) DNS CNAME record. In case of a fail-over you would change the value of the DNS CNAME record.
  • If your replica MS SQL Server is located in another region, you would simply boot up your fail-over application/web servers located in same region (assuming you would keep those server shut down at all time, to not incur billing, and boot them up in case of a fail-over). The standby/fail-over application/web servers would already be pointed to the replica EC2 SQL Server. And of course your main domain/subdomain DNS records should be pointed to the new primary region application/web servers.

Top of Page

Q 19. How far behind is the synchronization at any point in time. Looking at your testing it seems like it would be < 30 seconds in most scenarios.

A: The replication lag varies depending on certain factors, such as: if replication is within same region or cross-region, advanced configuration (i.e. reducing default limits on parallel table replications, with the purpose to further reduce impact on source, resulting to slight increase in replication latency ), number of tables, volume of changes per minute. In most cases it is < 30 seconds.

Top of Page

Q 20. Some versions of CloudBasic Multi-AR come with pre-installed MS SQL Server Standard or Web Edition. Can I extend the default data storage?

A: Yes. Follow these steps to Extend Default Data Storage

Top of Page

Q 21. How would we go back to the previous primary MS SQL Server once an outage is resolved?

A: Once the previous primary MS SQL Server is back up (or a new one is spun up in same or another zone or region, in the case where the entire zone or region is affected), a reverse replication form the newly promoted to primary MS SQL Server to the previous primary needs to be initiated (previous primary data is now outdated as data loss has occurred during the outage), followed by pointing your applications to the new primary.

Top of Page

Q 22. Can notifications be setup to alert us if there are any replication delays or outages?

A: You need to go to Configuration, enter SMTP parameters, and the DevOps email address the notifications need to be sent to, in the "email errors to:" fields.

Top of Page

Q 23. Will replications resume/catch up in case of any connectivity issues or if source or replica MS SQL Servers are taken down for maintenance? What is the allowed downtime?

A: CloudBasic supports resuming of replication in case of any prolonged downtime at the source or replica ends. Default retention period varies by product version. it is 8 days for the product version that comes with pre-installed replica MS SQL Server. It is 2 days in the product version that replicates to an external MS SQL Server. Default retention period can be adjusted during initial replication setup in the Quick Setup -> Advanced Settings.

Top of Page

Q 24. Does this product feature command line/API scheduling functionality?

A: CloudBasic features REST API designed for seamless integration with DevOps tools such as Jenkins and Go. HTTP Post calls are supported, which allows DB replications to be started in PowerShell scripts. Here is an example of integration with a DevOps tool scenario, utilizing PowerShell scripting:
http://cloudbasic.net/aws/rds/deploy/devops-scenario/.

Top of Page