sql server四种读写分离方案的小总结

这几天公司的数据库太tm的卡了，于是几个人在一起研究怎么加快速度，就搜了很多方法，然后我研究的是读写分离。

接着百度谷歌了很多读写分离的方案，发现这种图片出现在了很多地方

于是就研究了一些这四个方案，因为这四个表中写的东西反正我是完全无法理解。

所以自己研究了一下写了一份自己学习的总结(大部分是原文档加上自己的看法，还有很多部分待学习)

首先上原文档的地址

1.镜像(Database Mirroring)：https://docs.microsoft.com/en-us/sql/database-engine/database-mirroring/database-mirroring-sql-server?view=sql-server-2017
2.日志传送(Log Shipping)：https://docs.microsoft.com/en-us/sql/database-engine/log-shipping/about-log-shipping-sql-server?view=sql-server-2017

3.发布订阅(Subscribe to Publications)：https://docs.microsoft.com/en-us/sql/relational-databases/replication/subscribe-to-publications?view=sql-server-2017

4.永远在线可用性组(Aaways on):https://docs.microsoft.com/en-us/sql/database-engine/availability-groups/windows/overview-of-always-on-availability-groups-sql-server?view=sql-server-2017

---

 

1.镜像

官方地址：https://docs.microsoft.com/zh-cn/sql/database-engine/database-mirroring/database-mirroring-sql-server?view=sql-server-2017

一进去第一张图就是

 那么暂时抛弃看看其他的方案

---

2.日志传送（log shipping）

2.1 概述:

SQL Server的日志传送，可以自动从数据库上的主服务器发送事务日志的备份到一个或多个不同的辅助服务器的辅助数据库上。事务日志备份分别应用于每个辅助数据库。还有第三种服务器(可选)，称为监视服务器，它记录备份和还原操作的历史和状态，并可选地在这些操作未能按计划进行时发出警报。

 

2.2 优点：

2.2.1 为一个主数据库和一个或多个辅助数据库提供了灾难恢复的解决方案

2.2.2 可以对辅助数据库限制让他只可以执行读操作（在恢复操作的间隔时期）

    ps:这里的恢复操作时restore，具体的操作是辅助数据库将主数据库的事务记录还原到自己的数据库的操作

2.2.3 在主服务器备份主数据库的日志到辅助服务器必须还原日志备份的时间内可以指定延迟。

 

2.3 基本的原理(实例举例)：

2.3.1.主服务器在主数据库上执行备份操作，去备份事务的日志，这个服务器会将日志备份到主要的log-backup文件，这个文件会放到备份文件夹下，然后这个备份文件夹位于“Backup share”(一个共享的网络硬盘，也就是图里的UNC方式(网络硬盘共享))上

2.3.2.三个辅助服务器会执行他们的复制操作去复制主数据库的日志备份文件到自己的本地文件夹

2.3.3.三个辅助服务器会执行他们的恢复操作，将本地文件夹的日志备份还原到本地的辅助数据库中(个人见解应该就是重新运行日志上的操作)

2.3.4 主服务器和辅助服务器会发送他们自己的历史和状态到监控服务器上

---

3.发布订阅（Subscribe to Publications）

ps：这个其实涉及的是数据库的复制，在发布订阅中有很多的东西定义在这一个大项里面：https://docs.microsoft.com/en-us/sql/relational-databases/replication/sql-server-replication?view=sql-server-2017

所以下面的知识也知识自己的一下点总结和翻译

3.1 概述：

订阅是对发布的数据和数据库项目申请复制的一个请求，一个订阅定义了哪些请求会被收到以及会被收到哪里；当我们计划订阅时，需要思考在哪里进行代理处理；我们可以选择不同的订阅的种类来控制代理运行的位置；对于推送订阅，可以选择合并代理或者在不同的分发服务器上运行分发代理；对于请求订阅，代理在订阅服务器上运行；在订阅创建后，不能更改他的种类

3.2 订阅的种类：

3.2.1 推送订阅(Push Subscription):对于推送订阅，发布者不需要像订阅者申请就可以传送自己的更改。这些更改可以按需，按时间，按计划的进行推送。分发代理和合并代理会在分发服务器上运行。

3.2.2  请求订阅(Pull Subscription)：对于请求订阅，订阅者需要请求才可以在发布服务器上进行更改，请求订阅会使订阅服务器上的用户来确定何时进行同步数据的更改。分发代理和合并代理在订阅服务器上运行。

3.3 具体的实现：

csdn上有很多使用订阅来实现读写分离的blog，我也打算自己实现一遍，待更新，但是其实发布订阅涉及到的东西很多，自己也需要时间进行消化和理解，更多的是要去看原文档。其对于读写分离的应用其实就是有两个完全一样的数据库，将读操作和写操作分开。但是要怎么分开以及怎么更加有效率，则需要学习更多的知识。

原理图：（这个原理图可能更加好解释，原文的blog地址为:https://www.cnblogs.com/zqrios/p/7804111.html）

 

---

4.永远在线可用性组（always on）：

ps：always on 其实主要的原理是数据库业务的连续性和数据库的恢复，https://docs.microsoft.com/en-us/sql/database-engine/sql-server-business-continuity-dr?view=sql-server-2017

4.1 概述

可用性组为离散的用户数据库提供了一个可复制的环境，被称为可用性数据库；我们可以为高可用性(HA)或读取数据规模创建可用性组。HA可用性组是可以故障转移的一组数据库。读取数据规模可用性组是一组复制sqlserver的其他实例的进行只读负载的数据库。可用性组支持主数据库和一到八个辅数据库的集合，辅数据库不是备份只是定期备份数据库和事务日志。

ps.读取数据规模(read-scale)就是always on实现读写分离的原理了。

4.2 原理图

其实基本原理就是主数据库的事务日志记录发送到各个辅数据库上，但这个可能会有更好的可用性和恢复性。

实现待更新