Database mirroring
description
Transcript of Database mirroring
FlareCo Ltd
DATABASE MIRRORING
ALTER DATABASE AdventureWorks SET PARTNER FORCE_SERVICE_ALLOW_DATA_LOSS
Slide 1
FlareCo Ltd Database Mirroring. What is it?
• Is a mixture of replication and log shipping• It moves database transactions from one SQL Server database to another
SQL Server database on a different instance of SQL Server. • This mirrored copy is a standby copy and can not be accessed directly; it is
used only for a failover situation
Slide 2 Database Mirroring
FlareCo Ltd Database Mirroring: How does it work?
• At least 2 instances of SQL Server• Primary server is the "principal"
– This is the LIVE database• Secondary server is the "mirror.“
– This is the STANDBY • As transactions are written to the principal database they are also sent
and written to the mirrored database.
Slide 3 Database Mirroring
FlareCo Ltd Three modes of operation
• High Availability: – synchronizes transaction writes on both servers and enables automated
failover. – Needs a witness server to act as arbiter.
• High Protection: – synchronizes transaction writes on both servers, but failover is manual.
• High Performance: – Doesn’t care if the writes are synchronized on both servers, so is faster.– assumes that everything is going to complete successfully on the mirror.
Slide 4 Database Mirroring
FlareCo Ltd Relative merits
• Automatic failover to a secondary copy of your data is the real benefit of Database Mirroring.– So most implementation will probably use the High Availability mode.
• The other options still offer a built-in process for failing over, but require manual intervention
Slide 5 Database Mirroring
FlareCo Ltd The process
• Without Mirroring:• When a user makes a change to a database:
– Change is stored in the Log Buffer– Log Buffer is written to the Transaction Log
• This is called Hardening– Changes that have been written to the Transaction Log are Flushed (written)
to the database
Slide 6 Database Mirroring
FlareCo Ltd The process
• With Mirroring:• When a user makes a change to a database:
– SQL Server stores the change in the database’s log file– Log buffer is written to the transaction log AND principal server copies log
buffer to the mirror server– Mirror server hardens the transaction log– Changes are then flushed to the principal server’s database– Changes in the transaction log on the mirror server are replayed against the
mirror database, making it a copy of the principal
Slide 7 Database Mirroring
FlareCo Ltd
PRACTICAL EXERCISE
Slide 8
FlareCo Ltd
• First we shall produce a copy on the mirror server by backing up the sales database from the principal machine
• Then we shall set up the mirror environment
Slide 9 Database Mirroring
FlareCo Ltd The backup
Slide 10 Database Mirroring
FlareCo Ltd Backup the Database File
Slide 11
Note name and
directory for backup
Database Mirroring
FlareCo Ltd Backup the Transaction Log
Slide 12 Database Mirroring
FlareCo Ltd Restore the backup
Slide 13 Database Mirroring
FlareCo Ltd
Slide 14 Database Mirroring
FlareCo Ltd
Slide 15 Database Mirroring
FlareCo Ltd
Slide 16 Database Mirroring
FlareCo Ltd Set up the mirroring
Slide 17 Database Mirroring
FlareCo Ltd Click on Configure Security
Slide 18 Database Mirroring
FlareCo Ltd
Slide 19 Database Mirroring
FlareCo Ltd
Slide 20 Database Mirroring
FlareCo Ltd Leave accounts clear
Slide 21 Database Mirroring
FlareCo Ltd
Slide 22 Database Mirroring
FlareCo Ltd
Slide 23 Database Mirroring
FlareCo Ltd Don’t start Mirroring
Slide 24 Database Mirroring
FlareCo Ltd
LOG SHIPPING
Slide 25
FlareCo Ltd A note about recovery models
• full recovery, • simple recovery and • bulk-logged recovery. • The recovery models determine how much data loss is acceptable in case
of a failure and what types of backup and restore functions are allowed.
Slide 26 Log Shipping
FlareCo Ltd Simple
• The simple recovery model allows you to recover data only to the most recent full database or differential backup. Transaction log backups are not available because the contents of the transaction log are truncated each time a checkpoint is issued for the database.
Slide 27 Log Shipping
FlareCo Ltd Full
• The full recovery model uses database backups and transaction log backups to provide complete protection against failure. Along with being able to restore a full or differential backup, you can recover the database to the point of failure or to a specific point in time. All operations, including bulk operations such as SELECT INTO, CREATE INDEX and bulk-loading data, are fully logged and recoverable.
Slide 28 Log Shipping
FlareCo Ltd Bulk Logged
• Bulk-Logged• The bulk-logged recovery model provides protection against failure
combined with the best performance. • SELECT INTO, bulk-load operations, CREATE INDEX as well as text and
image operations are not logged• Under the bulk-logged recovery model, a damaged data file can result in
having to redo work manually based on the operations that are not fully logged
Slide 29 Log Shipping
FlareCo Ltd Use Simple when
– Your data is not critical. – Losing all transactions since the last full or differential backup is not an
issue. – Data is derived from other data sources and is easily recreated. – Data is static and does not change often. – Space is limited to log transactions. (This may be a short-term reason,
but not a good long-term reason.)
Slide 30 Log Shipping
FlareCo Ltd Bulk Logged when
– Data is critical, but logging large data loads bogs down the system. – Most bulk operations are done off hours and do not interfere with
normal transaction processing. – You need to be able to recover to a point in time.
Slide 31 Log Shipping
FlareCo Ltd Full when
– Data is critical and no data can be lost. – You always need the ability to do a point-in-time recovery. – Bulk-logged activities are intermixed with normal transaction
processing. – You are using replication and need the ability to resynchronize all
databases involved in replication to a specific point in time.
Slide 32 Log Shipping
FlareCo Ltd Log Shipping
• Copies transactions from a Primary Server to one or more Secondary Servers.
Slide 33 Log Shipping
FlareCo Ltd Server roles in Log Shipping
• Primary– The production server
• All log shipping takes place on this machine
• Secondary– Holds the standby copy of the database
• Initialise by restoring a backup from the primary– Use NORECOVERY or STANDBY option– STANDBY allows users read-only access to the database while backups are
restored
• Monitor– Tracks log shipping details
Slide 34 Log Shipping
FlareCo Ltd Jobs
• Four jobs are involved in Log Shipping• Backup
– Runs on primary server every 2 mins by default
• Copy– Runs on each secondary server just after the backup completes
• Restore– Restores on the secondary servers
• Alert– Optional – runs on the monitor server– Raises alerts on primary and secondary servers
Slide 35 Log Shipping
FlareCo Ltd Mirroring vs Log Shipping
Mirroring Log Shipping
Database log buffer is copied from one server to another and then replayed
Transaction log backups are sent to one or more secondary servers and then restored on each secondary server
One copy of original database Multiple copies on multiple servers
Provides immediate restore Delayed restore – Allows you to avoid logical errors
Slide 36 Log Shipping
FlareCo Ltd
LOG SHIPPING PRACTICAL EXERCISE
Slide 37
FlareCo Ltd
• Change the Recovery model to FULL• Backup the AdventureWorks database from the principal and restore it on
the secondary server• Ship the logs to the second instance
Slide 38 Log Shipping
FlareCo Ltd Changing the Recovery Model
Slide 39 Log Shipping
FlareCo Ltd Backup the database
Slide 40 Log Shipping
FlareCo Ltd Backup the Transaction Log
Slide 41 Log Shipping
FlareCo Ltd Restore the database to the secondary server
Slide 42 Log Shipping
FlareCo Ltd Configure Log Shipping
Slide 43 Log Shipping
FlareCo Ltd
Slide 44 Log Shipping
FlareCo Ltd
Slide 45 Log Shipping
FlareCo Ltd
Slide 46 Log Shipping
FlareCo Ltd
Slide 47 Log Shipping
FlareCo LtdClick OK to configure the log
shipping
Slide 48 Log Shipping
FlareCo Ltd Test the shipping
Slide 49 Log Shipping
FlareCo Ltd
Slide 50
Wait 5 minutes and then check to see that your record has been shipped t o the secondary database
Log Shipping
FlareCo Ltd
THE END
Slide 51