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.
Related
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
Can anyone explain the differences from a replication db vs a mirroring db server?
I have huge reports to run. I want to use a secondary database server to run my report so I can off load resources from the primary server.
Should I setup a replication server or a mirrored server and why?
For your requirements the replication is the way to go. (asumming you're talking about transactional replication) As stated before mirroring will "mirror" the whole database but you won't be able to query unless you create snapshots from it.
The good point of the replication is that you can select which objects will you use and you can also filter it, and since the DB will be open you can delete info if it's not required( just be careful as this can lead to problems maintaining the replication itself), or create specific indexes for the report which are not needed in "production". I used to maintain this kind of solutions for a long time with no issues.
(Assuming you are referring to Transactional Replication)
The biggest differences are: 1) Replication operates on an object-by-object basis whereas mirroring operates on an entire database. 2) You can't query a mirrored database directly - you have to create snapshots based on the mirrored copy.
In my opinion, mirroring is easier to maintain, but the constant creation of snapshots may prove to be a hassle.
As mentioned here
Database mirroring and database replication are two high data
availability techniques for database servers. In replication, data and
database objects are copied and distributed from one database to
another. It reduces the load from the original database server, and
all the servers on which the database was copied are as active as the
master server. On the other hand, database mirroring creates copies of
a database in two different server instances (principal and mirror).
These mirror copies work as standby copies and are not always active
like in the case of data replication.
This question can also be helpful or have a look at MS Documentation
I have a SQL server 2012 database on a server, which is a development database.
I want to create an another database on other machine which will be exact replica of the original one and as soon as any changes occur in schema and data it should get migrated to this second database.
I tried the log shipping method but in that case secondary database goes in Restoring mode whereas I want both the database active and functioning at the same time.
Performance or locks doesn't matter.
Any other easy way to do this? a utility that runs periodically automatically would also be great.
With log shipping the databases may be in readonly state most of the time, unless the periods when you run scheduled restore job.
Other options to consider - transactional replication, mirroring with readonly via snapshot or AlwaysOn Avalaibility groups with readable replicas, backup/restore (initial full backup/restore, then differential + trans logs) - but the last option is not for large databases.
I have a database on an SQL Server instance hosted on Azure Windows VM. There are two things I need to achieve.
Create a real-time duplicate of the database on another server. i.e. I need my database to make a copy of itself and then copy all of it's data to the duplicate at regular intervals. Let's say, 2 hours.
If my original database fails due to some reason, I need it to redirect all read/write requests to the duplicate database.
Any elaborate answer or links to any articles you deem helpful are welcome. Thank you!
You can have a high availability solution for your SQL Server databases in Azure using AlwaysOn Availability Groups or database mirroring.
Basically, you need 3 nodes for true HA. The third one can be a simple file server that will work as the witness to complete the quorum for your failover cluster. Primary and Secondary will be synchronized and in case of a failure, secondary will take over. You can also configure read requests to be split among instances.
If HA is not really that important for your use case, disaster recovery will be a cheaper solution. Check the article below for more info.
High Availability and Disaster Recovery for SQL Server in Azure Virtual Machines
https://azure.microsoft.com/en-us/documentation/articles/virtual-machines-sql-server-high-availability-and-disaster-recovery-solutions/
What is transaction replication used? I seemed to create transaction replication following this tutorial:
http://www.sql-server-performance.com/2010/transactional-replication-2008-r2/
And I know when I change some objects i.e any DML or DDL statement, those changes will be reflected to the other server where I did replication. But it's not clear to me why should we use transaction replication. Does SQL server automatically start using the 2nd server where replication was done when the main instance fails? or do we have to manually restore the database from the server where replication was done in case of failure of 1st instance?
Thanks in advance :)
You can use transactional replication to maintain a warm standby SQL server. Transactional replication replicates the data on one server (the publisher) to another server (the subscriber) with less latency than log shipping.
You can implement transactional replication at the database object level such as the table level. Therefore, Microsoft recommends that you use transactional replication when you have less data to protect, and you must have a fast data recovery plan.
This solution is vulnerable to the failure of the publisher and the subscriber at the same time. In such a scenario, you cannot protect your data. In all other scenarios such as the failure of a distributor or a subscriber, it is best to resynchronize the data in the subscriber with the data in the publisher.
You should use transactional replication to maintain a warm standby SQL server only when you do not implement schema changes or you do not implement other changes to your database such as security changes that replication does not support.
Note Replication is not designed for the maintenance of warm standby servers. With replication, you can use replicated data at the subscriber to generate reports. You can also use replication for other general uses without having to perform processing on your relatively busy publisher.
Disadvantages
Schema changes or security changes that are performed at the
publisher after establishing replication will not be available at
the subscriber. The distributor in transactional replication uses an
Open Database Connectivity (ODBC) connection or an OLE Database
(OLEDB) connection to distribute data. However, log shipping uses
the RESTORE TRANSACTION low-level Transact-SQL statement to
distribute the transaction logs. A RESTORE TRANSACTION statement is
much faster than an ODBC connection or an OLEDB connection.
Typically, switching servers erases replication configurations.
Therefore, you have to configure replication two times:
a. When you switch to the subscriber.
b. When you switch back to the publisher.
If a disaster occurs, you must manually switch servers by
redirecting all the applications to the subscriber.
Read more here http://sqlserverdatarecovery.com/transactional_replication.html