sqlserver关于mirror镜像的总结

命甴己造

mirror镜像的基本原理：主服务器上的主体数据库执行的增、删、改、查操作以日志的方法在镜像服务器的镜像数据库中重做。主体数据库创建镜像后，会启动一个单独的事务日志发送线程，维护一个虚拟的发送队列，然后读取事务日志，将其进行压缩，然后发送给 mirror 节点，mirror 节点接收到以后，会将其写入本地在磁盘上的一个重做队列文件中，然后再通过另外的一个线程异步的方式，从重做队列中获取事务日志，然后分发给应用线程(process unit)进行回放。

数据镜像的两种模式:
同步镜像操作：在事务传送中，主服务器必须等待镜像服务器返回成功接收日志的消息后，主服务器才继续下一事务日志到磁盘的写入与提交到镜像服务器。这种镜像不会造成数据丢失，但是存在镜像操作的事务延迟。

异步镜像操作：在事务传送中，主服务器不等待镜像服务器返回日志的接收情况，继续写下一事务日志到物理磁盘并提交给镜像服务器，这种镜像操作性能较高，但是主服务器宕机后可能造成镜像服务器数据丢失。

1、搭建mirror，必须先对主库进行全备和日志备份，并且要以norecovery方式把全备和日志恢复到从库，之后再在主库右键数据库-->properties-->mirror，参考图形界面一步步来搭建，如下是主库搭建mirror的报错,因为从库恢复的时候只恢复了数据库没有恢复日志导致

The mirror database, "XX", has insufficient transaction log data to preserve the log backup chain of the principal database. This may happen if a log backup from the principal database has not been taken or has not been restored on the mirror database.

2、图形界面搭建镜像过程中，跳出的端点名称会自动创建好，不需要手工先去创建，跳出的端点名称和端口可以自己定义，默认的是Mirroring和5022

3、搭建好后，监控mirror的工具，右键数据库-->Tasks-->Launch Database Mirroring Monitor,这个工具主库从库都有，效果一样，这点和log shipping的Transaction Log Shipping Status主库只负责主库，从库只负责从库不一样。

4、搭建好后，主库后面状态显示(Principal,Synchronized)，从库后面状态显示(Mirror,Synchronized/Restoring..)

5、搭建好后，主库和从库都有一个job名字是“Database Mirroring Monitor Job”，就算拆掉数据库的mirror，主从上该job还在，新增一个数据库的mirror，主备还是该job，没新增job，该job删除后，就算还有数据库的mirror，该job也不会自动重建，但是下次新增数据库的mirror时，该job会重建

6、因为从库的镜像数据库无法读，所以可以在从库创建快照数据库来读，来确定mirror是否真正的同步

7、如果想实现主从自动切换，即自动故障转移功能，必须要有见证服务器

8、如果主库故障了，从库状态变成(Mirror,Disconnected/In Recovery)，执行如下语句，恢复从库的读写状态(必须先执行第二条语句删除从库的快照，否则第三条语句无法执行)

ALTER DATABASE testdb SET PARTNER OFF;

drop database testdb_snapshot;

RESTORE DATABASE testdb WITH RECOVERY;

9、如果主库执行了移除remove镜像操作后需要删除从库再重新搭建主库从库的镜像，但是从库仍然显示(Mirror,Disconnected/In Recovery)，导致从库无法删除，且从库执行ALTER DATABASE testdb SET PARTNER OFF后状态仍是(Mirror,Disconnected/In Recovery)，则需要先在主库配置一下镜像，然后会报错镜像搭建不成功，这个时候从库状态显示(In Recovery),从库这时候可以直接删除。如果从库还是无法删除，就先在主库配置一下镜像，然后会报错镜像搭建不成功，再重启从库实例，从库状态一般会显示为(suspect),这时从库也可以直接删除了。

10、手动故障转移需要将事务安全设置为 FULL，且当伙伴连接在一起并且数据库已同步时即数据库处于 SYNCHRONIZED 状态时，才支持手动故障转移，登录主库执行如下语句，上面8非手动故障转移，因为数据库不是同步状态而是Disconnected/In Recovery

USE master;

ALTER DATABASE testdb SET PARTNER FAILOVER;

11、如果从库使用主库的全备和日志备份进行restore norecovery后，开始搭建mirror，但是这个过程中，mirror还没有搭建好，主库又备份了日志，mirror无法成功搭建，会有如下报错，只能把主库备份的日志再restore norecovery到从库，才可以正常搭建mirror

The remote copy of database <DatabaseName> has not been rolled forward to a point in time that is encompassed in the local copy of the database log

12、从库无法直接delete删除，这点和logshipping不一样

13、镜像故障查找，可以从主库和从库的日志中找相关信息

14、mirror数据库升级后，无法修改数据库版本COMPATIBILITY_LEVEL，因为mirror是只读的，暂停mirror也无法修改，因为数据库是restoring状态

15、mirror相关信息，可以参考视图sys.database_mirroring

16、mirror的从库，不能执行backup

17、主库升级后可以修改level，从库升级后无法修改level

18、主库新增datafile后，从库也会新增datafile，并且路径和主库的路径一样

19、mirror主库增加了文件，但是从库没有相应的目录，则同步会suspend挂起，就算从库有默认的datafile和logfile路径。在从库的数据库日志里面可以看到报错信息:CREATE FILE encountered operating system error 3(The system cannot find the path specified.) while attempting to open or create the physical file 'E:\XX\YY.ndf'.

20、FILETABLE的数据库无法搭建mirror，会报错A database cannot be enabled for both Database Mirroring and FILESTREAM or for both Database Mirroring and MEMORY_OPTIMIZED_DATA storage

21、搭建mirror时遇到一个怪异报错Database 'mirror_1' cannot be opened. It is in the middle of a restore。最后发现是因为数据库实例的版本是2016，而搭建mirror时使用的SSMS版本是2017，把SSMS换成2016就没有再报这个错误了，这个算是sqlserver的bug了

22 、 在从库创建镜像数据库mirror1的快照数据库mirror_snapshot， NAME必须等于等于主库里面的数据文件相同的逻辑名称， filename自己随意定义，指快照数据库的filename

create database mirror_snapshot on

(NAME=mirror1,filename='G:\DEFAULT.DATA\mirror_snapshot')

as snapshot of mirror1;

23、监控mirror数据库Db1最近的同步情况，可以参考如下语句（ 2表示最后4小时的行，如果把2改成1表示最后2小时的行 ）
USE msdb;   
EXEC sp_dbmmonitorresults Db1,2, 0;