sqlserver2008 复制,镜像,日志传输及故障转移集群区别
一, 数据库复制
SQL Server 2008数据库复制是通过发布/订阅的机制进行多台服务器之间的数据同步,我们把它用于数据库的同步备份。这里的同步备份指的是备份服务器与主服务器进行 实时数据同步,正常情况下只使用主数据库服务器,备份服务器只在主服务器出现故障时投入使用。它是一种优于文件备份的数据库备份解决方案。
SQL Server的复制分为种:
1. 快照发布:
发布服务器按预定的时间间隔向订阅服务器发送已发布数据的快照。每隔一段时间将订阅数据库中的相应表中的数据全部删除,然后将自己相应表中的全部插到订阅数据库中
使用快照复制本身是最合适的:
1)很少更改数据。
2)在一段时间内允许具有相对发布服务器已过时的数据副本。
3)复制少量数据。
4)在短期内出现大量更改。
在数据更改量很大,但很少发生更改时,快照复制是最合适的。 例如,如果某销售组织维护一个产品价格列表且这些价格每年要在固定时间进行一两次完全更新,那么建议在数据更改后复制完整的数据快照。 对于给定的某些类型的数据,更频繁的快照可能也比较适合。 例如,如果一天中在发布服务器上更新相对小的表,但可以接受一定的滞后时间,则可以在夜间以快照形式传递更改。
发布服务器上快照复制的连续开销低于事务复制的开销,因为不用跟踪增量更改。 但是,如果要复制的数据集非常大,那么若要生成和应用快照,将需要使用大量资源。 评估是否使用快照复制时,需要考虑整个数据集的大小以及数据的更改频率。
2. 事务发布:
在订阅服务器收到已发布数据的初始快照后,发布服务器将事务流式传输到订阅服务器。
事务复制通常从发布数据库对象和数据的快照开始。 创建了初始快照后,接着在发布服务器上所做的数据更改和架构修改通常在修改发生时(几乎实时)便传递给订阅服务器。 数据更改将按照其在发布服务器上发生的顺序和事务边界应用于订阅服务器,因此,在发布内部可以保证事务的一致性。
以下各种情况下适合采用事务复制:
1). 希望发生增量更改时将其传播到订阅服务器。
2). 从发布服务器上发生更改,至更改到达订阅服务器,应用程序需要这两者之间的滞后时间较短。
3). 应用程序需要访问中间数据状态。 例如,如果某一行更改了五次,事务复制将允许应用程序响应每次更改(例如,激发触发器),而不只是响应该行最终的数据更改。
4).发布服务器有大量的插入、更新和删除活动。
5).发布服务器或订阅服务器不是 SQL Server 数据库(例如,Oracle)。
默认情况下,事务发布的订阅服务器应视为只读,因为更改将不会传播回发布服务器。 但是,事务复制确实提供了允许在订阅服务器上进行更新的选项
3. 具有可更新订阅的事务发布:
在 SQL Server 订阅服务器收到已发布数据的初始快照后,发布服务器将事务流式传输到订阅服务器。来自订阅服务器的事务被应用于发布服务器。
4. 合并发布:
在订阅服务器收到已发布数据的初始快照后,发布服务器和订阅服务器可以独立更新已发布数据。更改会定期合并。Microsoft SQL Server Compact Edition 只能订阅合并发布。
与事务复制相同,合并复制通常也是从发布数据库对象和数据的快照开始, 并且用触发器跟踪在发布服务器和订阅服务器上所做的后续数据更改和架构修改。 订阅服务器在连接到网络时将与发布服务器进行同步,并交换自上次同步以来发布服务器和订阅服务器之间发生更改的所有行。
合并复制通常用于服务器到客户端的环境中。 合并复制适用于下列各种情况:
1). 多个订阅服务器可能会在不同时间更新同一数据,并将其更改传播到发布服务器和其他订阅服务器。
2). 订阅服务器需要接收数据,脱机更改数据,并在以后与发布服务器和其他订阅服务器同步更改。
3). 每个订阅服务器都需要不同的数据分区。
4). 可能会发生冲突,并且在冲突发生时,您需要具有检测和解决冲突的能力。
5). 应用程序需要最终的数据更改结果,而不是访问中间数据状态。 例如,如果在订阅服务器与发布服务器进行同步之前,订阅服务器上的行更改了五次,则该行在发布服务器上仅更改一次来反映最终数据更改(也就是第五次更改的值)。
合并复制允许不同站点自主工作,并在以后将更新合并成一个统一的结果。 由于更新是在多个节点上进行的,同一数据可能由发布服务器和多个订阅服务器进行了更新。 因此,在合并更新时可能会产生冲突,合并复制提供了多种处理冲突的方法
复制的缺点: 表有主键,而且表结构日后不能更改,如果架构稳定也是不错的,如果有很多张表那就比较麻烦了
转载于:https://blog.51cto.com/finchina/1748778