I have a scenario where there are multiple databases in a single RDS instance. Let's call them A, B & C.
Is it possible to take a snapshot of just one database (say A or B) & not the entire RDS instance?
How can we recover just a single database from the snapshot of that particular database?
From what I have read & understood, RDS supports Automated Backups & Database Snapshots, both of which take a snapshot of the entire RDS instance rather than at the more granular (DB) level.
Related
What are the main differences between sql-server replication and availability groups in an Azure Iaas data solution? (sql server instances on a VM)
Are these the same concept?
SQL Server Replication copies data and replays changes using SQL Commands to replicas. Sometimes this is called "Logical Replication". Replication is typically not used for High-Availibility or Disaster Recovery, but can be used to create a readable replica of a production database or to copy selected data from a main database into one or more subscribers.
AlwaysOn Availibility Groups copies and applies the log records to syncronize databases. The changes are applied using the same transaction log redo process that's used in backup/restore and database recovery. Sometimes this is called "Physical Replication", as the database files on every replica are identical. AlwaysOn Availibility Groups can be used for High-Availitbiiy, Disaster Recovery, and to create Readable Replicas of a production database.
I want to migrate my SQL Server Databases to AWS EC2 instances or AWS RDS using DMS Service of AWS?
How can I do that? What will be the architecture for the same? How to secure Databases in AWS?
What is the difference between both approaches? Can anyone provide architecture for both the approaches?
We're in the middle of moving our on-prem SQL Servers to AWS EC2 right now. For us, we're adding replicas to existing Availability Groups. When the time comes, we'll fail over the AG and tada! we'll be in AWS. But even if we didn't have AGs, I'd still do this with backup/restore over DMS. From the little bit that I looked at DMS, you need either CDC or a rowversion column on every table you want DMS to work with. Which seemed like a lot to me.
In case you're not acquainted with moving a database with backup/restore, here's the bones of it.
Copy a full backup to the target system
Restore that backup, being sure to specify with norecovery to allow it to accept more backups
Copy/restore a differential backup, again specifying with norecovery
Copy/restore transaction log backups. You'll keep doing this on a periodic basis until you're ready to do your cut over.
When you're finally ready to turn off the source database, take a log backup of the source, specifying with norecovery. This will create what is called a tail of the log backup and will stop anything from being able to write to the source database. Copy/restore that last log backup over and you're migrated.
I want a solution that match the below scenario:
We have 2 databases with 1 being the main DB and the other being the secondary DB. I want a process (executable, powershell, anything...) that can update the changes that I make in Stored Procedures in the main DB. the main DB is the database that we will make the changes then I want a process that update (simple delete and create) the older SP in the secondary DB.
How I can make this possible in the most simply way? If you will say software to work with please take in account that I only want freeware.
It seemed like you are defining something called Mirroring if I didn't assume wrong.
Database mirroring maintains two copies of a single database that must reside on different server instances of SQL Server Database Engine. Typically, these server instances reside on computers in different locations. Starting database mirroring on a database, initiates a relationship, known as a database mirroring session, between these server instances.
One server instance serves the database to clients (the principal server). The other instance acts as a hot or warm standby server (the mirror server), depending on the configuration and state of the mirroring session. When a database mirroring session is synchronized, database mirroring provides a hot standby server that supports rapid failover without a loss of data from committed transactions. When the session is not synchronized, the mirror server is typically available as a warm standby server (with possible data loss).
https://learn.microsoft.com/en-us/sql/database-engine/database-mirroring/database-mirroring-sql-server?view=sql-server-2017
Hope it helps
We have a master SAP Sybase database A in country C1 and we need a read only copy of the sybase database B in country C2 (currently hosted in hyper-v). We are currently doing this backup using full and incremental backup. The problem is that it is taking too long to mail the tape and do full database restore at the site B. We have established a VPN connection and the bandwidth is not big. We can accept a few day latency. What are my options besides (using replication server) to do this database synchronisation as corporate situation do not allow spending of extra $.
Our full corporate backup data amounts to 5 TB in size.
Thanks.
Patrick
Without using Replication Server, the simplest solution is probably to use log shipping. This utilizes the transaction log from one database to synchronize another database.
After an initial dump of the Database A has been loaded in Database B, you would setup scheduled transaction log dumps, and load those dumps in Database B. After the initial load, the dump sizes would depend on the database transaction rate, so the more activity in the database, the larger the dumps will be.
A couple of things to note:
This will likely require more transaction log storage space on Database A.
Database B will not be accessible during the transaction loading time.
A good description of this and other options can be found in this SAP article on Business Continuity
We have an asp.net mvc web application with IIS and SQL Server residing in the same Amazon EC2 instance. We plan to move the database from the EC2 instance to Amazon RDS (to improve performance, the application is a bit slow at the moment - high cpu usage on the server).
I can't figure how this could be potentially helpful. On the flip side.
Migrating the database to Amazon RDS is not straightforward
Amazon RDS does not allow change in allocated storage for SQL Server
You can not use Backup / Restore to move DBs in and out of RDS
What are the benefits of migrating a SQL Server DB from EC2 to RDS? Rather than migrating to RDS should we look to resize the EC2 instance itself?
The biggest benefit to migrating to RDS, imo, is that your database becomes a database-as-a-service: you no longer need to manage it like you do when its running on your own instance. Automated backups, ability to take a snaphot and spin up an identical instance etc - all great things.
A while back I migrated all the SQL databases I supported to RDS and slept very well at night no longer needing to worry about them - but then, little by little, all the problems you mentioned became clearer and harder to ignore - inability to take backups of a single db and use locally, no longer have true administrator privileges to the DB or server and so ultimately, in a furry of activity migrated everything back to my own EC2 instances over a weekend.
IMO, until RDS allows you to take a local single-database backup and restore it to RDS, (and the opposite allow you to take a single database in RDS and make a backup that can be restored locally), I don't consider RDS to be a viable solution for me for any solution that is likely to need changes.
If I had a system that was 100% 'done', (if there is such a thing), and no need to enhance, modify, customize the database, than RDS has some benefits - but not having the ability to import/export backups is a show stopper for me as long as there is any chance I may need to make changes down the road - for the life of me can't figure out why AWS has not allowed/enabled this feature.
As to what you should do, first and foremost, you need to make sure that the database is really the bottleneck - it might not be.
If it is, then:
If you are not already, start using a cache in front of your database
Upgrade the size of your ec2 instance.
Split the database onto its on EC2 instance.
Moving your database to RDS has some benefits, but an immediate boost in performance is not necessarily one of them.