论文部分内容阅读
【摘 要】本文首先分析了应用层数据库的高可用性，之后介绍关于SQL Server服务器故障转移群集方面理论。
【关键词】应用层数据库 系统灾备 高可用性
一、应用层数据库高可用性方式分析
（一）主从方式（非对称方式）。主机工作，备机处于监控准备状况；当主机宕机时，备机接管主机的一切工作，待主机恢复正常后，按使用者的设定以自动或手动方式将服务切换到主机上运行，数据的一致性通过共享存储系统解决。采用这种方式实现系统的高可用性是一个比较稳妥的方案。因为采用这种方式实现高可用性，只有一台主服务器在工作，另一台备份服务器只是通过心跳线进行简单的监视，负载并不高，所以当主备服务器进行切换后，备份服务器只是简单的承接了主服务器上的负载，不会对备份服务器的负载造成很大的冲击。因此采用这种方式实现高可能用性是一个相对稳妥的方案，但是在使用过程中就会造成一台服务器一直处于低负载的状态，无法实现均衡负载，实现成本比较高。操作系统采用这种方式实现高可用性的应用比较多，数据库采用这种方式实现高可用性的应用比较少。数据库会在操作系统中成为一个被监视的服务或进程，实现操作系统级的高可用性。
（二）双机双工方式（互备互援）。两台主机同时运行各自的服务工作且相互监测情况，当任一台主机宕机时，另一台主机立即接管它的一切工作，保证工作实时。采用这种方式实现系统的高可用性不仅能够实现数据的容灾，还可以实现均衡负载的功能。但是如果服务器1出现异常，服务器2接管服务器1的服务，就会对服务器2的负载造成很大的冲击。操作系统很少采用这种方式实现高可用性，但是数据库却有这样的产品会采用这种方式实现高可用性。
（三）集群工作方式（多服务器互备方式）。多台主机一起工作，各自运行一个或几个服务，各为服务定义一个或多个备用主机，当某个主机故障时，运行在其上的服务就可以被其它主机接管。集群工作方式就是由两台机器的互备互援扩展成多台服务器的互备互援。这种工作方式也有Share Disk和Share Nothing的模式区分。这种集群工作方式结构更加复杂，随着服务器的增加，数据复制，内存同步等操作都会对系统负载及网络造成很大的冲击。
二、应用层数据库灾备分析及解决方案
（一）灾备分析。备份是容错的补充，合适的灾备方案会使数据更加安全。备份又分为冷备份和热备份。冷备份就是指系统在关闭状态下，不会产生数据交互的情况下进行的备份。因为冷备份需要停止应用，所以目前冷备份的应用越来越少，只有在系统建立初期或进行系统的大规模改造时，进行冷备份作为系统运行的一个基线。热备份与之相对，就是在系统运行的情况下对数据进行备份，因为无需停止应用，所以热备份被广泛应用。备份数据的过程中对系统资源的消耗比较少，但是恢复数据将是一个相对漫长的过程。所以在制定灾备方案的时候，一定要考虑备份对系统资源的消耗以及数据恢复造成宕机的时间是否可以接受。在制定备份方案时，还应该考虑备份数据的存放问题。数据备份到本地，效率高，易于维护和管理，但是数据的安全性不高，如果本地存储出现问题，备份数据也有可能受到破坏，即使备份数据没有被破坏，系统恢复将非常麻烦，恢复时间将会很漫长。所以在制定备份方案时，还应该考虑异地备份的问题，以及备份数据异地恢复的问题。
（二）数据库灾备的解决方案。根据上面的数据库灾备分析本文认为应采取以下方案来解决应用层数据库灾备问题：
1.首先要制定本地备份的备份计划，然后再完成异地备用机器的建设。就数据库而言，本地备份的技术已经相当完善，我们需要考虑的就是备份对系统资源的消耗，所以在制定本地备份计划时，首先要考虑备份时间，尽量是在系统相对比较空闲的时间进行备份。其次要考虑备份时长，长时间的备份不仅消耗系统资源，而且在备份期间出现灾难的概率也相应的增加了，所以要尽量缩短备份时长。
2.根据不同的备份方式选择不同的解决方案。各个数据库异地备份的实现方式有所不同，第一是分析数据库日志进行数据同步，第二是传送日志文件到备份服务器上，在备份机器上恢复日志文件实现数据同步。第一种方式数据可以实现实时同步，但是因为要实现在主备机器上都要成功的写入数据，这就造成数据写入效率相应的降低。
第二种方式只传送日志文件，所以对数据的写入效率影响不大，但是备份数据库需要恢复这些日志文件才能使用，做不到数据的实时同步。SQL Server 故障转移群集构建于 Windows Server 故障转移群集之上。Windows服务器故障转移集群旨在提供高可用性服务或应用程序集群内运行故障转移。它包含一组独立运行的服务器来提高应用程序和服务的可用性。
故障转移集群可以防止硬件和软件故障， 将故障资源从一个服务器 （或集群节点） 转移到另一个的节点。故障转移是一个过程， 以一个集群服务或应用程序在一个节点上离线，并将它重新联机在另一个节点。整个过程对用户是透明的。SQL Server 故障转移群集又称为故障转移群集实例，它包括：一个或多个 Windows Server 故障转移群集节点；SQL Server 故障转移群集专用群集资源组，其中包含：（1）用来访问 SQL Server 故障转移群集的网络名称（2）IP 地址（3）用于 SQL Server 数据库和日志存储的共享磁盘（4）在所有故障转移群集节点中自动保持同步的检查点注册表项。
SQL Server 故障转移群集在网络上显示为一台计算机上的单个 SQL Server 实例。在群集内部，一次只有一个节点拥有群集资源组，满足针对该故障转移群集实例的所有客户端请求。在出现故障（硬件故障、操作系统故障、应用程序或服务故障）或进行计划升级时，组所有权就转移至故障转移群集内的其他节点。此过程称为故障转移。通过利用 Windows Server 故障转移群集功能，SQL Server 故障转移群集通过冗余在实例级别提供了高可用性。
参考文献：
[1]曲智辉.数据库同步技术在灾备系统中的应用研究[D].兰州大学，2011.
[2]李生帛.浅析数据库灾备的重要性[J].信息安全与技术，2012，（12）.
【关键词】应用层数据库 系统灾备 高可用性
一、应用层数据库高可用性方式分析
（一）主从方式（非对称方式）。主机工作，备机处于监控准备状况；当主机宕机时，备机接管主机的一切工作，待主机恢复正常后，按使用者的设定以自动或手动方式将服务切换到主机上运行，数据的一致性通过共享存储系统解决。采用这种方式实现系统的高可用性是一个比较稳妥的方案。因为采用这种方式实现高可用性，只有一台主服务器在工作，另一台备份服务器只是通过心跳线进行简单的监视，负载并不高，所以当主备服务器进行切换后，备份服务器只是简单的承接了主服务器上的负载，不会对备份服务器的负载造成很大的冲击。因此采用这种方式实现高可能用性是一个相对稳妥的方案，但是在使用过程中就会造成一台服务器一直处于低负载的状态，无法实现均衡负载，实现成本比较高。操作系统采用这种方式实现高可用性的应用比较多，数据库采用这种方式实现高可用性的应用比较少。数据库会在操作系统中成为一个被监视的服务或进程，实现操作系统级的高可用性。
（二）双机双工方式（互备互援）。两台主机同时运行各自的服务工作且相互监测情况，当任一台主机宕机时，另一台主机立即接管它的一切工作，保证工作实时。采用这种方式实现系统的高可用性不仅能够实现数据的容灾，还可以实现均衡负载的功能。但是如果服务器1出现异常，服务器2接管服务器1的服务，就会对服务器2的负载造成很大的冲击。操作系统很少采用这种方式实现高可用性，但是数据库却有这样的产品会采用这种方式实现高可用性。
（三）集群工作方式（多服务器互备方式）。多台主机一起工作，各自运行一个或几个服务，各为服务定义一个或多个备用主机，当某个主机故障时，运行在其上的服务就可以被其它主机接管。集群工作方式就是由两台机器的互备互援扩展成多台服务器的互备互援。这种工作方式也有Share Disk和Share Nothing的模式区分。这种集群工作方式结构更加复杂，随着服务器的增加，数据复制，内存同步等操作都会对系统负载及网络造成很大的冲击。
二、应用层数据库灾备分析及解决方案
（一）灾备分析。备份是容错的补充，合适的灾备方案会使数据更加安全。备份又分为冷备份和热备份。冷备份就是指系统在关闭状态下，不会产生数据交互的情况下进行的备份。因为冷备份需要停止应用，所以目前冷备份的应用越来越少，只有在系统建立初期或进行系统的大规模改造时，进行冷备份作为系统运行的一个基线。热备份与之相对，就是在系统运行的情况下对数据进行备份，因为无需停止应用，所以热备份被广泛应用。备份数据的过程中对系统资源的消耗比较少，但是恢复数据将是一个相对漫长的过程。所以在制定灾备方案的时候，一定要考虑备份对系统资源的消耗以及数据恢复造成宕机的时间是否可以接受。在制定备份方案时，还应该考虑备份数据的存放问题。数据备份到本地，效率高，易于维护和管理，但是数据的安全性不高，如果本地存储出现问题，备份数据也有可能受到破坏，即使备份数据没有被破坏，系统恢复将非常麻烦，恢复时间将会很漫长。所以在制定备份方案时，还应该考虑异地备份的问题，以及备份数据异地恢复的问题。
（二）数据库灾备的解决方案。根据上面的数据库灾备分析本文认为应采取以下方案来解决应用层数据库灾备问题：
1.首先要制定本地备份的备份计划，然后再完成异地备用机器的建设。就数据库而言，本地备份的技术已经相当完善，我们需要考虑的就是备份对系统资源的消耗，所以在制定本地备份计划时，首先要考虑备份时间，尽量是在系统相对比较空闲的时间进行备份。其次要考虑备份时长，长时间的备份不仅消耗系统资源，而且在备份期间出现灾难的概率也相应的增加了，所以要尽量缩短备份时长。
2.根据不同的备份方式选择不同的解决方案。各个数据库异地备份的实现方式有所不同，第一是分析数据库日志进行数据同步，第二是传送日志文件到备份服务器上，在备份机器上恢复日志文件实现数据同步。第一种方式数据可以实现实时同步，但是因为要实现在主备机器上都要成功的写入数据，这就造成数据写入效率相应的降低。
第二种方式只传送日志文件，所以对数据的写入效率影响不大，但是备份数据库需要恢复这些日志文件才能使用，做不到数据的实时同步。SQL Server 故障转移群集构建于 Windows Server 故障转移群集之上。Windows服务器故障转移集群旨在提供高可用性服务或应用程序集群内运行故障转移。它包含一组独立运行的服务器来提高应用程序和服务的可用性。
故障转移集群可以防止硬件和软件故障， 将故障资源从一个服务器 （或集群节点） 转移到另一个的节点。故障转移是一个过程， 以一个集群服务或应用程序在一个节点上离线，并将它重新联机在另一个节点。整个过程对用户是透明的。SQL Server 故障转移群集又称为故障转移群集实例，它包括：一个或多个 Windows Server 故障转移群集节点；SQL Server 故障转移群集专用群集资源组，其中包含：（1）用来访问 SQL Server 故障转移群集的网络名称（2）IP 地址（3）用于 SQL Server 数据库和日志存储的共享磁盘（4）在所有故障转移群集节点中自动保持同步的检查点注册表项。
SQL Server 故障转移群集在网络上显示为一台计算机上的单个 SQL Server 实例。在群集内部，一次只有一个节点拥有群集资源组，满足针对该故障转移群集实例的所有客户端请求。在出现故障（硬件故障、操作系统故障、应用程序或服务故障）或进行计划升级时，组所有权就转移至故障转移群集内的其他节点。此过程称为故障转移。通过利用 Windows Server 故障转移群集功能，SQL Server 故障转移群集通过冗余在实例级别提供了高可用性。
参考文献：
[1]曲智辉.数据库同步技术在灾备系统中的应用研究[D].兰州大学，2011.
[2]李生帛.浅析数据库灾备的重要性[J].信息安全与技术，2012，（12）.