数据库备份，数据库镜像，数据库读写分离的介绍
sqlserver2008R2
1.数据库备份和恢复模式
1.1备份方式
SQLServer2008提供了四种备份方式：完整备份、差异备份、事务日志备份、文件和文件组备份。
完整备份
备份整个数据库的所有内容，包括事务日志。该备份类型需要比较大的存储空间来存储备份文件，备份时间也比较长，在还原数据时，也只要还原一个备份文件。
差异备份
差异备份是完整备份的补充，只备份上次完整备份后更改的数据。相对于完整备份分来说，差异备份的数据量比完整数据备份小，备份的速度也比完整备份要快。因此，差异备份通常作为常用的备份方式。在还原数据时，要先还原前一次做的完整备份，然后还原最后一次所做的差异备份，这样才能让数据库里的数据恢复到与最后一次差异备份时的内容相同。
事务日志备份
事务日志备份只备份事务日志里的内容。事务日志记录了上一次完整备份或事务日志备份后数据库的所有变动过程。事务日志记录的是某一段时间内的数据库变动情况，因此在进行事务日志备份之前，必须要进行完整备份。与差异备份类似，事务日志备份生成的文件较小、占用时间较短，但是在还原数据时，除了先要还原完整备份之外，还要依次还原每个事务日志备份，而不是只还原最后一个事务日志备份（这是与差异备份的区别）。
文件和文件组备份
如果在创建数据库时，为数据库创建了多个数据库文件或文件组，可以使用该备份方式。使用文件和文件组备份方式可以只备份数据库中的某些文件，该备份方式在数据库文件非常庞大时十分有效，由于每次只备份一个或几个文件或文件组，可以分多次来备份数据库，避免大型数据库备份的时间过长。另外，由于文件和文件组备份只备份其中一个或多个数据文件，当数据库里的某个或某些文件损坏时，可能只还原损坏的文件或文件组备份。
举例说明
完整备份
例如，在2012年1月1日早上8点进行了完整备份，那么将来在还原时，就可以恢复到2012年1月有1日早上8点时的数据库状态。
差异备份
差异备份是备份完整备份后的数据变动情况。例如，在2012年1月1日早上8点进行了完整备份后，在1月2日和1月3日又分别进行了差异备份，那么在1月2日的差异备份里记录的是从1月1日到1月2日这一段时间里的数据变动情况，而在1月3日的差异备份里记录的是从1月1日到1月3日这一段时间里的数据变动情况。因此，如果要还原到1月3日的状态，只要先还原1月1日做的完整备份，再还原1月3日做的差异备份就可以了。
事务日志备份
事务日志备份是以事务日志文件作为备份对象，相当于将数据库里的每一个操作都记录下来了。假设在2012年1月1日早上8点进行了完整备份后，到1月2日早上8点为止，数据库里的数据变动了100次，如果此时做了差异备份，那么差异备份记录的是第100次数据变动后的数据库状态，而如果此时做了事务日志备份，备份的将是这100次的数据变动情况。
再举一个例子，例如在2012年1月1日早上8点进行了完整备份后，在1月2日和1月3日又进行了事务日志备份，那么在1月2日的事务日志备份里记录的是从1月1日到1月2日这一段时间里的数据变动情况，而在1月3日的事务日志备份里记录的是从1月2日到1月3日这一段时间里的数据变动情况。因此，如果要还原到1月3日的数据，需要先还原1月1日做的完整备份，再还原1月2日做的事务日志备份，最后还要还原1月3日所做的事务日志备份。
备份方式的选择
了解了以上数据库备份方式后，便可以针对自己的数据库利用以上方式来备份数据库了。合理备份数据库需要考虑几方面，首先是数据安全，其次是备份文件大小，最后是做备份和还原能承受的时间范围。
数据变动量较小
例如，如果数据库里每天变动的数据量很小，可以每周（周日）做一次完整备份，以后的每天（下班前）做一次事务日志备份，那么一旦数据库发生问题，可以将数据恢复到前一天（下班时）的状态。
当然，也可以每周（周日）做一次完整备份，以后的每天（下班前）做一次差异备份，这样一旦数据库发生问题，同样可以将数据恢复到前一天下班时的状态。只是一周的后几天做差异备份时，备份的时间和备份的文件都会跟着增加。但这也有一个好处，在数据损坏时，只要恢复完整备份的数据和前一天差异备份的数据即可，不需要去恢复每一天的事务日志备份，恢复的时间会比较短。
数据变动量较大
如果数据库里的数据变动得比较频繁，损失一个小时的数据都是十分严重的损失时，用上面的办法备份数据就不可行了，此时可以交替使用三种备份方式来备份数据库。
例如，每天下班时做一次完整备份，在两次完整备份之间每隔八小时做一次差异备份，在两次差异备份之间每隔一小时做一次事务日志备份。如此一来，一旦数据损坏可以将数据恢复到最近一个小时以内的状态，同时又能减少数据库备份数据的时间和备份数据文件的大小。
数据库文件较大
在前面还提到过当数据库文件过大不易备份时，可以分别备份数据库文件或文件组，将一个数据库分多次备份。在现实操作中，还有一种情况可以使用到数据库文件的备份。例如在一个数据库中，某些表里的数据变动得很少，而某些表里的数据却经常改变，那么可以考虑将这些数据表分别存储在不同的文件或文件组里，然后通过不同的备份频率来备份这些文件和文件组。但使用文件和文件组来进行备份，还原数据时也要分多次才能将整个数据库还原完毕，所以除非数据库文件大到备份困难，否则不要使用该备份方式。
尾部日志备份
针对以上备份方案，能看出数据还是不完整吗？比如昨天夜间12点做了完整备份，每隔一小时做了一次事务日志备份，最后一次事务日志备份是今天中午12点，现在是今天中午12点10分，发现数据库数据遭到丢失或破坏，可最后一次事务日志备份是今天中午12点，如果我此时将数据库恢复到12点，那么12点后至12点10分前没遭到破坏的操作数据将丢失（比如数据库有三个表，一个表的数据遭到破坏，其它两个表的数据被其它用户变动）。此时就要用到【尾部日志备份】，尾部日志备份原理是从最后一次事务日志备份的时间点开始，将之后的所有操作进行备份，还原时便可以找到12点后操作的正确数据了。
注：进行尾部日志备份时，数据库将强制停止数据库，此时如果不停止数据库，还有用户继续操作，尾部日志备份将失去意义。SQLServer2012如果你最后一次备份事务日志后，对数据进行过改动，即发生过事务日志（也就是当前日志文件记录的LSN(日志***)大于最后一次事务日志备份里记录的最大LSN，SQLServer通过LSN来区分日志的记录），并尚未对尾部日志备份，它会提示并要求你必须先做尾部备份。
1.2完整恢复模式
为默认恢复模式。它会完整记录下操作数据库的每一个步骤。使用完整恢复模式可以将整个数据库恢复到一个特定的时间点，这个时间点可以是最近一次可用的备份、一个特定的日期和时间或标记的事务。
大容量日志恢复模式
简单地说就是要对大容量操作进行最小日志记录，节省日志文件的空间（如导入数据、批量更新、SELECTINTO等操作时）。比如一次在数据库中插入数十万条记录时，在完整恢复模式下每一个插入记录的动作都会记录在日志中，使日志文件变得非常大，在大容量日志恢复模式下，只记录必要的操作，不记录所有日志，这样一来，可以大大提高数据库的性能，但是由于日志不完整，一旦出现问题，数据将可能无法恢复。因此，一般只有在需要进行大量数据操作时才将恢复模式改为大容量日志恢复模式，数据处理完毕之后，马上将恢复模式改回完整恢复模式。
简单恢复模式
在该模式下，数据库会自动把不活动的日志***，因此简化了备份的还原，但因为没有事务日志备份，所以不能恢复到失败的时间点。通常，此模式只用于对数据库数据安全要求不太高的数据库，并且在该模式下，数据库只能做完整和差异备份。
可以看出三种恢复模式的区别在于对“日志”的处理方式不同，就“日志”大小来看：完全恢复模式>大容量日志恢复模式>简单恢复模式。
2.数据库镜像
数据库镜像维护一个数据库的两个副本，这两个副本必须驻留在不同的 SQL Server 数据库引擎服务器实例上。 通常，这些服务器实例驻留在不同位置的计算机上。 启动数据库上的数据库镜像操作时，在这些服务器实例之间形成一种关系，称为“数据库镜像会话” 。
其中一个服务器实例使数据库服务于客户端（主体服务器）。 另一个服务器实例则根据镜像会话的配置和状态，充当热备用或温备用服务器（镜像服务器）。 同步数据库镜像会话时，数据库镜像提供热备用服务器，可支持在已提交事务不丢失数据的情况下进行快速故障转移。 未同步会话时，镜像服务器通常用作热备用服务器（可能造成数据丢失）。
在“数据库镜像会话 ”中，主体服务器和镜像服务器作为“伙伴 ”进行通信和协作。 两个伙伴在会话中扮演互补的角色：“主体角色” 和“镜像角色” 。 在任何给定的时间，都是一个伙伴扮演主体角色，另一个伙伴扮演镜像角色。 每个伙伴拥有 其当前角色。 拥有主体角色的伙伴称为“主体服务器” ，其数据库副本为当前的主体数据库。 拥有镜像角色的伙伴称为“镜像服务器” ，其数据库副本为当前的镜像数据库。 如果数据库镜像部署在生产环境中，则主体数据库即为“生产数据库 ”。
数据库镜像涉及尽快将对主体数据库执行的每项插入、更新和删除操作“重做 ”到镜像数据库中。 重做通过将活动事务日志记录的流发送到镜像服务器来完成，这会尽快将日志记录按顺序应用到镜像数据库中。 与逻辑级别执行的复制不同，数据库镜像在物理日志记录级别执行。 从 SQL Server 2008开始，在事务日志记录的流发送到镜像服务器之前，主体服务器会先将其压缩。 在所有镜像会话中都会进行这种日志压缩。
3.数据库读写分离
在MS Sql server中可以使用发布定义的方式实现数据库复制，实现读写分离，复制是将一组数据从一个数据源拷贝到多个数据源的技术，是将一份数据发布到多个存储站点上的有效方式。使用复制技术，用户可以将一份数据发布到多台服务器上。复制技术可以确保分布在不同地点的数据自动同步更新，从而保证数据的一致性。SQL SERVER复制技术类型有三种，分别是：快照复制、事务复制、合并复制。SQL SERVER 主要采用出版物、订阅的方式来处理复制。源数据所在的服务器是出版服务器，负责发表数据。出版服务器把要发表的数据的所有改变情况的拷贝复制到分发服务器，分发服务器包含有一个分发数据库，可接收数据的所有改变，并保存这些改变，再把这些改变分发给订阅服务器。
为了实现数据库读写分离，应用程序需要作如下调整：
-
在应用程序的配置文件中设置两个数据库连接字符串，一个指向主服务器，一个指向查询服务器；
-
增删改或者实时性查询使用指向主服务器的连接字符串；
-
允许非实时的查询及报表请求使用指向查询服务器的连接字符串。
SQL Server提供了三种技术，可以用于读写分离的实现：日志传送、事务复制和SQL Server 2012中新增的功能Always On技术。这三种技术的比较如下：
4.性能比较【推荐镜像和快照组合】
数据库镜像--数据库快照--数据库复制是数据库开发人员耳熟能详的一些名词了，那么他们究竟有什么好处和优势呢？举个很简单的例子，一个统计往往会对一个操作比较频繁的数据库造成很大的影响，例如数据库有1000w的数据，你sum一下或者去模糊查询一下，那估计这个程序需要卡N秒，这样就对其他操作造成了非常大的影响，如果有一个一模一样的镜像，那么就算造成N+N秒，对于主数据库也是没有影响的，在这里简单说一下各个操作的优势和缺点，欢迎拍砖
①：数据库镜像：最低要求：2005以上版本，必须sp1以上补丁
介绍：数据库镜像就和我们普通的系统ghost镜像类似，就是一个备份，只是不同是，这个镜像和数据库是实时同步的，可以看做每秒钟都在备份
优势：镜像服务器最大是优势就是备份，当你是服务器崩溃时，你可以立即启动镜像服务器，使其正常运行，这个就是镜像服务器最大的优势
劣势：既然要备份，那么性能消耗是肯定的，但是综合其他几种相比起来，这个消耗基本上是在可接受的范围之内的，而且个人感觉不好的地方之一就是镜像数据库无法访问的，需要将镜像数据库快照以后再进行访问，要是可以直接访问就爽了，当然这个只是幻想一下。
②：数据库快照：
介绍：数据库快照就想象成相机就可以了，就是将数据库拍下来，拍摄个一模一样的。做一次备份
优势：类似一个人成长，有很多张照片，例如你每年拍一张，那么以后查看起来是非常方便的。
劣势：这个无法做到实时备份，只能是某一刻的一个备份，很多需求会不满足，而且如果数据量非常大，那么对性能也有一定的的消耗
③：数据库复制：（这个可不是数据库备份还原哦）
介绍：也是两个库，一个主库一个从库，主从库之间是一种发布订阅的关系，就是我修改了通知你，或者你时时来读取我，看看我是否修改了，就这么简单
优势：他是读取的日志文件，根据日志文件达到同步的，所以基本可以满足同步，并且我错略的测试了一下，除非服务器堵塞，否则性能还是很高的，百万数据同步几秒钟就可以完成，足见其效率了。
劣势：发布者和订阅者之间并非实时同步的，所以经常会有延时，这个就属于不定性因素的，而且消耗>数据库镜像 .
以上模式就使用而言，镜像和快照组合还是一个蛮不错的选择的。至于具体每种的具体用法，稍后的文章会逐一更新
4.参考：
http://www.infocool.net/kb/Sqlserver/201707/387604.html 备份和恢复
https://docs.microsoft.com/zh-cn/sql/database-engine/database-mirroring/database-mirroring-sql-server 数据库镜像
http://tech.it168.com/a2012/0110/1300/000001300144_all.shtml 读写分离