SQL Server 中使用镜像、日志传送、复制和集群的场景有哪些
据我所知，SQL Server 提供了 4 种技术来提高可用性。
我认为这些是主要的使用场景，总结一下：-
1）复制主要适用于在线-离线数据同步场景（笔记本电脑、移动设备、远程服务器）。
2) 日志传送可用于拥有手动切换的故障转移服务器，而
3) 数据库镜像是一种自动故障转移技术
4) 故障转移集群是数据库镜像的高级类型。
我对吗 ？
谢谢。
As far as i know SQL Server provides 4 techniques for better availability.
I think these are the primary usage scenarios, in summary :-
1) Replication would be primarily suited for online-offline data synchronization scenarios (laptop , mobile devices, remote servers).
2) Log shipping could be used to have a failover server with manual switching, whereas
3) Database Mirroring is an automatic failover technique
4) Failover Clustering is an advanced type of database mirroring.
Am i right ?
Thanks.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
故障转移群集是一种在硬件级别提供冗余的可用性技术，它构建于 Windows 群集技术之上，即它并非特定于 SQL Server。
例如，服务器 A 上的处理器崩溃了。幸运的是，服务器 A 是 SQL Server 群集的一部分，因此服务器 B 在几秒钟内接管了提供 SQL Server 服务的工作。 所有这些都是自动发生的，并且对于数据库用户和/或集群所服务的应用程序来说是透明的。
数据库镜像和集群之间的主要区别在于，SQL 集群在实例级别提供冗余，而数据库镜像在数据库级别提供冗余。
以下链接提供了您可能会用到的这两种技术之间的比较。
http://msdn.microsoft.com/en-us/ library/ms191309(SQL.90).aspx
日志传送更多地被认为是一种冗余技术。
例如，它可用于提供主环境的完整副本，通常用作可手动联机的热备份。 这可用于为您的备份策略提供额外的冗余。
通过在备用位置/服务器上创建生产数据库的只读副本，日志传送还可用于从主服务器卸载报告。
复制是一种相当多样化的技术，可用于满足许多不同的场景，其选择将决定所实现的特定复制类型。
例如，合并复制可用于通过将应用程序的工作负载分散到多个服务器（即分布式处理架构）来支持分布式处理。
合并复制通常需要应用程序相对了解其环境。 还必须考虑冲突解决等技术，以确保整个集成环境中的数据一致性。
事务复制可以以与日志传送类似的方式使用，但是您可以限制复制到订阅者的特定对象。 如果仅需要表的子集用于报告目的，这会很有用。
我希望这能让你明白一点。 您可以在 SQL Server 在线书籍中找到有关每种技术的大量文档，或者通过在 Google 中搜索每种技术来找到。 也就是说，如果您有任何具体疑问，我很乐意提供帮助，请随时给我留言。
干杯，约翰
Failover clustering is an availability technology that provides redundancy at the hardware level and is built on top of Windows Clustering technology, i.e. it is not specific to SQL Server.
For example, the processor blows up on Server A. Fortunately Server A is part of a SQL Server Cluster and so Server B takes over the job of providing the SQL Server Service, within a matter of seconds. All of this occurs automatically and is transparent to the database users and or application being served by the cluster.
The main difference between Database Mirroring and clustering is that SQL Clustering provides redundancy at the instance level whereas database mirroring provides redundancy at the database level.
The following link provides a comparison between these two technologies that you may find of use.
http://msdn.microsoft.com/en-us/library/ms191309(SQL.90).aspx
Log shipping is considered more of a redundancy technology.
For example, it can be used to provide a full copy of your primary environment, typically used as a warm standby that can be manually brought online. This can be used to provide additional redundancy to your backup strategy.
Log shipping can also be used to offload reporting from a primary server by creating a read only copy of the production database at an alternative location/server.
Replication is quite a diverse technology and can be used to cater for a number of different scenarios, the choice of which will determine the specific type of replication that is implemented.
For example, merge replication can be used to support distributed processing by spreading the workload of an application across several servers, i.e. distributed processing architectures.
Merge replication often requires an application that is relatively aware of its environment. Techniques such as conflict resolution also have to be taken into consideration in order to ensure data consistency across the entire integrated environment.
Transactional Replication can be used in a similar fashion to log shipping however you can limit the specific objects that are replicated to the subscriber. This can be useful if only a subset of tables is required for reporting purposes.
I hope this clears things up for you a little. You can find a wealth of documentation regarding each of these technologies within SQL Server books online, or by searching for each technology in Google. That said if you have any specific queries I would be happy to help so feel free to drop me line.
Cheers, John
在 SQL 2008 Enterprise 中，还有一种称为更改数据捕获 (CDC) 的功能，我们在我的工作中成功地使用了它。
我们有一个过度规范化的数据库，这使得获取信息变得非常困难。 我们需要在将此数据复制到另一台服务器以进行报告等的同时更改数据结构。
它对我们来说非常有效。
In SQL 2008 Enterprise there is also something called Change Data Capture (CDC) which we are using successfully where I work.
We have an overly normalized database which makes it too hard to get information out. We needed to change the data structure at the same time as we replicate this data to another server for reports and such.
It works extremely well for us.
AFAIK 日志传送和复制可能更适合相反的方式。
日志传送是计划同步，因此复制更适合手动切换，因为备份服务器将尽可能保持最新，除非您有任何通信问题（但是，日志传送也会有同样的问题）。
离线数据对延迟不像备份服务器那么敏感，但就我个人而言，我根本没有真正看到日志传送的必要性，我看不出它什么时候会成为复制的更合适替代方案（但可能是在sql2005之前没有实现复制）
也许我将复制与镜像混淆了，请注意，镜像不会为您提供自动故障转移，只有HA集群为您提供该功能，这意味着：
至少使用SQL server 2005 标准、Windows Enterprise 和共享数据存储（如 SAN）。
AFAIK log shipping and replication would probably be better suited the other way around.
Log shipping is scheduled synchronization, therefor replication would be better suited for manual switching because the backup-server would be as up to date as it could be unless you had any communication-problem (however, log shipping would have the same issue).
offline-data isn't as sensitive to delays as a backup-server, but personally I don't really see the need for log-shipping at all, I can't see when it ever would be a more suitable alternative to replication (but it could be that replication wasn't implemented before sql2005)
Maybe I'm confusing replication with mirroring, and as a note, mirroring doesn't give you automatic failover, only HA-cluster gives you that functionality, meaning:
using atleast SQL server 2005 standard, Windows Enterprise and a shared data-storage (like a SAN).