|
|
马上注册，结交更多好友，享用更多功能，让你轻松玩转社区。
您需要 登录 才可以下载或查看，没有帐号？立即注册
x
对于insert操作，只需要把event_type改成DELETE_ROWS_EVENT；对于delete操作，改成WRITE_ROWS_EVENT 如今来存眷一下数据库镜像形态，从主服务器和数据库入手下手。
主服务器数据库形态
当safety设置为FULL，主数据库的一般操纵形态时SYNCHRONIZED形态。当safety设置为OFF，主数据库的一般操纵形态是SYNCHRONZING形态。
◆假如safety设置为FULL，主数据库的肇端形态一直是SYNCHRONIZING，当主数据库和镜像数据库事件日记同步后，数据库形态就转换成SYNCHRONIZED，
◆假如safety设置为FULL而且主服务器断开了和见证服务器的毗连但仍然能够举行事件处置，那末数据库形态为exposed。
◆假如safety设置为FULL而且主服务器没法和其他服务器构成quorum，那末将没法供应数据库服务。不同意任何的用户毗连和事件处置。
下表显现了主数据库大概的形态，和招致形态转换的一些事务。
表5：主数据库形态，safety为FULL和safety为OFF
Safety
主服务器初始形态
事务
招致了局
Quorum
Exposed
可否供应数据库服务
FULL
SYNCHRONIZING
同步产生
SYNCHRONIZED
是
否
是
FULL
SYNCHRONIZED
会话停息
SUSPENDED
是
是
是
FULL
SYNCHRONIZED
镜像服务器上呈现Redo毛病
SUSPENDED
是，利用见证服务器
是
是
否，没有见证服务器
-
否
FULL
SYNCHRONIZED
镜像服务器不成用
DISCONNECTED
是，利用见证服务器
是
是
否，没有见证服务器
-
否
OFF
SYNCHRONIZING
会话停息
SUSPENDED
-
是
是
OFF
SYNCHRONIZING
镜像服务器上呈现Redo毛病
SUSPENDED
-
是
是
OFF
SYNCHRONIZING
镜像服务器不成用
DISCONNECTED
-
是
是
当safety设置为FULL，主数据库起首进进SYNCHRONIZING形态，只需和镜像数据库同步，两个同伴都进进SYNCHRONIZED形态。当safety设置为OFF，同伴数据库从SYNCHRONIZING形态入手下手并在全部镜像过程当中坚持该形态。
关于这两个safety设置，假如会话被挂起大概呈现了镜像服务器的redo毛病，那末主数据库进进SUSPENDED形态。假如镜像服务器不成用，那末主数据库进进DISCONNECTED形态。
在DISCONNECTED和SUSPENDED形态下：
◆当safety设置为FULL，假如主服务器没法和见证服务器大概镜像服务器自称quorum，那末主数据库被视为exposed。这意味着主数据库为举动形态，撑持用户毗连和事件处置。可是没有日记纪录被发送到镜像数据库。因而假如主数据库失利了，那末镜像数据库不包括任何自立数据库进进exposed形态后主服务器上产生的事件。一样的，也不成以清算主数据库的事件日记，这招致日记文件的无穷增加。
◆当safety设置为FULL，假如主服务器没法和其他服务器构成quorum，它将不克不及供应数据库服务。一切用户将被断开毗连，也不同意新的事件处置。
◆当safety设置为OFF，朱数据库被视为exposed，由于没有事件日记纪录被发送到镜像。
注重：ManagementStudiosObjectExplorer会在Server树图中数据库称号的中间呈报主数据库形态。将主数据库的SYNCHRONIZED形态呈报为Principal,Synchronizing，DISCONNECTED形态呈报为Principal,Disconnected.
镜像数据库形态
镜像数据库具有和主数据库不异的形态，可是因为镜像数据库一直处于nonrecovered形态，因而在承当镜像脚色的时分不克不及供应数据库服务。下表显现了能够招致镜像服务器和数据库形态改动的一些最多见事务。
表6：镜像服务器形态，safety为FULL和safety为OFF
Safety
镜像服务器形态
事务
招致的了局
FULL
SYNCHRONIZING
同步产生
SYNCHRONIZED
FULL
SYNCHRONIZED
会话停息
SUSPENDED
FULL
SYNCHRONIZED
镜像服务器上呈现Redo毛病
SUSPENDED
FULL
SYNCHRONIZED
主数据库不成用
DISCONNECTED
OFF
SYNCHRONIZING
会话停息
SUSPENDED
OFF
SYNCHRONIZING
镜像服务器上呈现Redo毛病
SUSPENDED
和主数据库一样，ManagementStudiosObjectExplorer在Server树的数据库称号中间呈报镜像数据库形态。镜像数据库的SYNCHRONIZED形态呈报为Mirror,Synchronizing，DISCONNECTED形态呈报为Mirror,Disconnected.
见证服务器形态
在sys.database_mirroring目次视图中有三种见证服务器形态，CONNECTED、DISCONNECTED和UNKNOWN。
表7：Witness服务器形态（纪录在同伴服务器上）
见证服务器形态
事务
招致的了局
CONNECTED
见证服务器不成用
DISCONNECTED
主服务器没法初始化镜像
UNKNOWN
</p><p> 因为见证服务器形态真正纪录在同伴服务器而不是见证服务器上，因而这些形态是从有益于同伴的角度来设置的，因而当您看到见证服务器为DISCONNECTED形态时，意味着同伴和见证服务器断开了。数据库镜像启动后，假如镜像服务器没法与主服务器举行初始化，那末见证服务器进进UNKNOWN形态。 传输事件日记纪录
SQLServer主服务器和镜像服务器传输动静和日记纪录的序次依据事件平安性的设置而分歧。我们先研讨同步传输，然后再研讨异步传输。
当SQLServer将事件事务纪录在事件日记中时，日记纪录被写进磁盘前临时寄存在日记缓冲区中。数据库镜像时，每第二天志缓冲区被输入到硬盘时（软化），主服务器也将不异的日记纪录块发送到镜像服务器。
1.当safety设置为FULL，只需SQLServer主服务器软化它的日记纪录块，就同时将不异的日记纪录块发送到镜像服务器，并以为当地的日记I/O和远程镜像服务器的日记I/O从实质下去说是一样的。这类传输称为同步的，由于在一个事件提交之前，主服务器既要守候当地的I/O（软化）还要守候守候镜像服务器有关完成I/O（软化）的回复。
每次主服务器大概镜像服务器软化日记缓冲区时，城市将缓冲区中最高的日记序列号（LSN）+1作为mirroring_failover_lsn纪录在元数据中。
mirroring_failover_lsn用于协商事件日记最初的保证点，如许两个同伴数据库就能够在初始化时坚持同步，在妨碍转移后也坚持同步。
当主服务器发送日记纪录给镜像服务器时，主服务器上的mirroring_failover_lsn一般会提早一些。镜像服务器软化日记纪录时会纪录其mirroring_failover_lsn，然后复兴主服务器。可是等主服务器吸收到来自镜像切实其实认信息时，主服务器大概已入手下手软化新的一组日记纪录了。
表8显现了主服务器和镜像服务器safety为FULL时的一个事务序列示例。
表8：Safety为FULL（同步传输）事务序列的示例
ServerA
ServerB
Principal,Synchronized
Mirror,Synchronized
入手下手一个包括数据更新的多语句事件
主数据库的事件日记纪录被放进事件日记缓冲区
事件日记缓冲区内容被写进磁盘（软化），日记纪录块被发送到镜像服务器，主服务器纪录日记块的mirroring_failover_lsn，然后守候镜像服务器切实其实认。
镜像服务器吸收日记纪录并放进事件日记缓冲区
镜像服务器将日记缓冲区输入到磁盘，纪录mirroring_failover_lsn，然后关照主服务器日记块已被软化
主服务器吸收日记纪录已被镜像服务器软化到磁盘的关照
镜像服务器持续从头实行REDO行列中的事件日记
包括了COMMIT的日记写进事件日记缓冲区
事件日记缓冲区内容被写进磁盘（软化），
包括了COMMIT的日记纪录块被发送到镜像服务器，主服务器纪录日记块的mirroring_failover_lsn，然后守候镜像服务器切实其实认。
镜像服务器吸收日记纪录并放进事件日记缓冲区
镜像服务器将日记缓冲区输入到磁盘，纪录themirroring_failover_lsn，然后关照主服务器日记块已被软化
主服务器吸收日记纪录已被镜像服务器软化到磁盘的关照，至此全部事件提交
镜像服务器持续从头实行REDO行列中包括了COMMIT的事件日记，修正数据页面
新事件被写进主服务器的日记缓冲区
以上事务序列中关头的一点就是：当safety设置为FULL时，主服务器软化日记缓冲区和将日记缓冲区中日记纪录的正本发送到镜像服务器，两者是同时举行的。然后主服务器入手下手守候本人的I/O和镜像服务器的I/O，两个I/O都完成后才以为事件完成了。当主服务器吸收到来自镜像的回复后，再入手下手处置下一次软化。
当safety设置为FULL时，只管主服务器和镜像服务器之间和谐严密，可是数据库镜像不是散布式事件，也不利用两阶段提交协定。
◆在数据库镜像中，两个事件分离在两台服务器上实行，并非一个跨服务器的散布式事件。
◆数据库镜像不利用同伴服务器作为散布式事件中的资本办理器。
◆数据库镜像事件不履历筹办和提交阶段。
◆最主要的是，镜像服务器上事件提交失利不会招致主服务器上的事件会滚，这一点与散布式事件分歧。
2.当safety设置为OFF时，主服务器不守候来自镜像服务器切实其实认动静，因而主服务器上已提交事件数目大概多于镜像服务器，如所示：
表9：Safety为OFF（异步传输）事务序列的示例
ServerA
ServerB
Principal,Synchronizing
Mirror,Synchronizing
入手下手一个包括数据更新的多语句事件
数据更新的事件日记纪录被写进事件日记缓冲区
事件日记缓冲区内容被强迫输入到磁盘（软化），日记纪录块被发送到镜像服务器，主服务器纪录日记块的mirroring_failover_lsn
包括了COMMIT的日记被写进事件日记缓冲区，加上其他的事件举动
镜像服务器吸收日记纪录并放进事件日记缓冲区
事件日记缓冲区内容被写进磁盘，
包括了COMMIT的日记纪录块被发送到镜像服务器
镜像服务器将日记缓冲区输入到磁盘，纪录themirroring_failover_lsn，然后关照主服务器日记块已被软化
提交事件
镜像服务器持续从头实行REDO行列中的事件日记
镜像服务器吸收日记纪录并放进事件日记缓冲区
镜像服务器将日记缓冲区输入到磁盘，纪录themirroring_failover_lsn，然后关照主服务器日记块已被软化
数据库镜像脚色转换
能够从数据库镜像服务器大概使用程序的角度来思索数据库镜像妨碍转移成绩。从数据库镜像服务器角度，妨碍转移就是将镜像服务器转换为主服务器，和利用新恢复的数据库作为主数据库。妨碍转移能够是主动的、手动的、大概forcedservice。
◆主动的–只要高可用形式下才会发生（safety设置为FULL和见证服务器的介入）
◆手动的- 只要高可用和高回护操纵形式下才会发生（safety设置为FULL），两个同伴数据库都是SYNCHRONIZED。
◆Forcedservice（同意数据丧失）-次要是在高功能形式下（safetyOFF）用于立即和手动的恢复镜像数据库
当safety设置为FULL时，用于交换服务器脚色的最好的体例是利用手动妨碍转移，而不是forcedservice。
主动妨碍转移
主动妨碍转移是高可用形式下（safety为FULL利用见证服务器）数据库镜像的功效。年夜多半情形下，SQLServer能够在几秒钟内完成主动妨碍转移。SQLServer能够举行部分主动妨碍转移，由于包括在数据库镜像会话中的SQL服务器会相互测试对方的存在。该历程称为“ping”，但包括的操纵远不止一个一般的IP地点ping。镜像服务器和见证服务器接洽主服务器以反省主物理服务器是不是存在、SQLServer是不是存在、和主数据库是不是可用。相似的，主服务器和见证服务器ping镜像服务器以反省镜像物理服务器和SQLServer实例的可用性，和镜像数据库的复原形态。
假定利用safetyFULL和见证服务器设置了数据库镜像。镜像服务器即ServerB经由过程ping发明主服务ServerA不成用。ServerB与见证服务器通讯并收到见证服务器也看不到ServerA切实其实认动静。那末ServerB将和见证服务器构成quorum并将本人提拔为主服务器脚色。它将恢复它的数据库而且关照见证服务器现在本人承当了主服务器的脚色（只管数据库处于disconnected形态，新主数据库的事件日记也不克不及被截断）。
ServerB的新主数据库持续从头实行事件日记中的举动，可是它将延续redo形态并且年夜多半情形下只要很少的事情必要完成。在一切SQLServer版本中，新主数据库只需完成redo历程就立即可用了。当数据库进进undo形态时将能够吸收用户毗连了。完成redo一般只需几秒钟，只管余下的undo阶段工夫大概很长。在数据库镜像中，新的主数据库只需redo阶段完成绩能够为用户毗连供应服务。新主服务器B的数据库处于DISCONNECTED形态并且是exposed，可是只需redo历程完成绩能够供应数据库服务。
一般将全部使用程序从主服务重视新定向到新主服务器消费的工夫要多于数据库镜像的主动妨碍转移。使用程序必需检测和重试毗连，如许也会增添该历程的全体工夫。别的，假如将新的SQLServer考证上岸账号增加到服务器，还必要利用体系存储历程sp_change_users_login将这些上岸账户映照到新主数据库的用户账户。假如旧的主服务器上一些关头工具，如SQLAgent功课还没有拷贝到新主服务器上，也会延误使用程序妨碍转移的完成。（更多信息请浏览该白皮书完成数据库镜像部分的“为妨碍转移筹办镜像服务器”）
如今假定旧的主服务器联机了。假如是手动妨碍转移，大概旧的主服务器被疾速修复的主动妨碍转移场景，两台服务器必要举行脚色交换，那末就必需举行一个协商历程。在数据库镜像从头入手下手之前，两台同伴服务器必要决意相互如何举行同步。镜像妨碍转移lsn这个过程当中饰演了一个关头脚色。
ServerA（新镜像服务器）掉队了，但它其实不分明本人掉队了几。ServerA向serverB（新主服务器）呈报它从serverB吸收的最初的镜像妨碍转移lsn。另外一方面，ServerB因为某些提交的事情而招致它有最新的镜像妨碍转移lsn，serverA必需要追逐上serverB。ServerB将充足数目的事件日记发送给serverA，使serverA经由过程从头这些实行事件并与ServerB同步。
手动妨碍转移
手动妨碍转移就是顺次互换两个同伴服务器的脚色。它请求safety设置为FULL，而且主服务器和镜像服务器处于SYNCHRONIZED形态。
在主服务器上利用上面的ALTERDATABASE命令举行手动妨碍转移：
ALTERDATABASEAdventureWorksSETPARTNERFAILOVER; 大概在ManagementStudio的DatabaseProperties/Mirroring对话框中单击Failover按钮。手动妨碍转移在旧的主数据库上断开一切用户毗连并回滚一切未完成的事件。经由过程完成一切redo行列中已提交的事件，回滚一切未完成的事件（在undo阶段）来恢复镜像数据库。旧的旧的镜像数据库被分派了主数据库脚色，而旧的主数据库则承当新的镜像数据库脚色。两台服务器依据它们的镜像妨碍转移lsn协商数据库镜像的新出发点，然后处置脚色交换。
可使用手动妨碍转移作为完成操纵体系大概SQLSERVER实例的‘转动晋级’的一种体例来，假设您在初始化镜像服务器之前起首晋级镜像服务器。更多信息请参阅SQLServerBooksOnline中ManualFailover主题。
ForcedService
在镜像服务器上利用ALTERDATABASE命令举行forcedService：
ALTERDATABASEAdventureWorksSETPARTNERFORCE_SERVICE_ALLOW_DATA_LOSS; 一般只要当safety为OFF而且主服务器再也没法运转时才利用这类体例。也能够在safety为FULL使利用该命令，可是假如恢复的镜像服务器没法构成quorum，它也不克不及供应数据库服务。因而最幸亏safety为OFF（高功能操纵形式）是利用该命令。因为异步的数据传输没法包管镜像数据库包括一切主服务器上提交的最新事件，因而有些数据大概会丧失。
数据库镜像可用性场景
在这一部分，您将依据以下两类事务对数据库镜像预期的可用性了局举行研讨：
◆一个或多个服务器大概数据库失利
◆服务器之间一条或多条通讯连路失利
服务器失利多是因为某个镜像同伴数据库、大概某个SQLSERVER实例不成用。别的，即便服务器自己能够持续运转，可是数据库镜像同伴服务器之间的通讯连路大概中止。
以了局景中，两个组件的同时失利被视为一个组件紧接着另外一个组件的按次失利。比方，ServerA和B呈现了同时失利，镜像体系将该事务视为一个按次事务：ServerA失利然后ServerB失利，大概反过去。
利用上面的划定规矩来判断一个不成用事务的预期了局：
1.当safety设置为FULL时，主服务器必要最少一台其他服务器才干构成quorum来坚持数据库可用。
假如主服务器没法构成quorum，也就没法再供应数据库服务了。
2.当safety设置为FULL，假如镜像服务器和见证服务器都没法接洽到主服务器，那末镜像服务器能够和见证服务器构成quorum而且改动其脚色，使之成为新的主服务器。
这就是主动的妨碍转移。
3.当safety设置为FULL，假如主服务器和见证服务器互助构成quorum，可是断开了和镜像服务器的毗连，那末主服务器失利将不同意镜像服务器和见证服务器构成quorum，也不同意镜像服务器承当主服务器的脚色。
如许能够避免所做的事情因为会话中止而丧失。
4.当safety设置为FULL，假如失利的主服务器在停机大概伶仃后从头到场会话，同时旧的镜像服务器已承当了主服务器的脚色（和见证服务器构成quorum），那末旧的主服务器将在此次会话中承当新镜像服务器脚色。
在妨碍转移过程当中，镜像服务器和见证服务器会增添镜像脚色按次计数器。由于主服务器的镜像脚色按次计数器小于另外一个同伴服务器和见证服务器的按次计数器，因而那两台服务器会在旧的主服务重视新到场会话之前构成quorum并入手下手事情。旧的主服务器承当起镜像的脚色。
5.当safety设置为FULL而且会话中没有见证服务器，大概见证不知何以加入了会话，镜像同伴服务器的失利将招致没法构成quorum，主服务器也因而不再坚持主数据库可使用。
没法构成quorum，因而不成能举行主动的妨碍转移，假如见证服务器不包括在safety为FULL的会话中。
高可用处景中服务器失利
高可用操纵形式下的数据库镜像其目标就是尽量增添数据库的可用性。在这类形式下，假如主数据库没法会见，那末数据库镜像将敏捷使镜像数据库能够承受会见。鄙人面的一组场景中，我们的会商将从高可用设置加上三台自力的服务器入手下手。
鄙人面的高可用处景中，ServerA作为主服务器启动，ServerB是镜像服务器，而ServerW是见证服务器，如所示：
：示例数据库镜像会话在高可用操纵形式下启动
一切这三台服务器能够在统一个站点利用局域网毗连，也能够在分歧的站点利用WAN举行毗连。ServerA和ServerB能够交换脚色，可是ServerW一直作为见证服务器。
如今来思索假如个中一台服务器呈现妨碍时发生的了局。
场景HASL1.1：主服务器失利
上面的场景剖析了在高可用形式下主服务器失利时会产生甚么。显现了分歧的脚色，和镜像同伴之间怎样做脚色转换。
：在高可用形式下，当主服务器ServerA失利，妨碍转移产生
主服务器ServerA失利后，镜像和见证服务器构成quorum，主动的妨碍转移发生。假如从头恢复了原始的主服务器，它将承当起镜像服务器的脚色。
注重：要招致高可用形式下的妨碍转移，失利能够产生在分歧的级别上：服务服务器大概停机、主服务器上的SQLSERVER实例大概中断大概失利、服务器上的主数据库大概不成用或形态可疑。鄙人面场景中，主服务器失利大概由这些事务中的任何一个引发。
由于ServerB和W能够构成quorum，而且两者均没法接洽ServerA，那末ServerB能够将本人提拔为新的主服务器。可是假如没有镜像服务器，镜像会话就被以为是exposed。
ServerA恢复后，它成为新的主服务器，镜像会话也不再是exposed。
单服务器失利事务其实不多见，两台服务器失利就更少见了，因而研讨在这类情形下呈现的了局非常有效。
两台服务器能够同时大概几近同时失利，但从数据库镜像的角度来看，其了局被视为一台服务器失利紧接着另外一台也失利了。因而这些场景只思索当多台服务器按次失利时的成果。
接上去的两个场景剖析主服务器ServerA失利，紧接着其他两台服务器也失利时会发生的了局。
◆新的主服务器ServerB失利；
◆见证服务器ServerW失利；
场景HASL1.2：主服务器失利，随后新的主服务器失利
同后面的场景一样，在高可用操纵形式下，假如主服务器起首失利，那末妨碍转移产生。显现了假如新的主服务器接上去也失利了，那末不管如何恢复这些服务器，新的主服务器（ServerB）一直坚持其主服务器的脚色。
：因为主服务器失利，接着新主服务器也失利而招致脚色转换
ServerA失利后，ServerB成为新的主服务器，可是没法将数据发送给镜像服务器，因而主服务器处于exposed，即便它仍旧供应数据库服务。当ServerA失利紧接着ServerB也失利，那末就不存在数据库镜像了，由于ServerB已复工了。
假如ServerA起首恢复，它从见证服务器的mirroring_role_sequence号中检测到见证服务器已构成了新的quorum。
ServerA回收了镜像服务器的脚色，然后守候ServerB恢复。ServerB一旦恢复，立即入手下手了和ServerA的数据库镜像历程。假如ServerB先恢复，那末就从头回到了在HASL1。1中显现的初始场景。
注重：假如ServerW在ServerA和ServerB接踵失利后也宣布失利，招致一切三台服务器均复工，那末不管以甚么序次恢复见证服务器，已转换完成的ServerA和ServerB的脚色将坚持稳定。
场景HASL1.3：主服务器失利，随后见证服务器失利
主服务器失利后产生妨碍转移。见证服务器大概接上去也失利，如所示：
：见证服务器紧随原始主服务器呈现失利，那末新主服务器没法供应数据库服务
当见证服务器ServerW主服务器ServerA失利后也呈现失利，那末新主服务器ServerB仍然为主服务器但被伶仃，没法构成quorum，也不克不及供应数据库服务。
假如ServerA起首恢复，ServerB的mirroring_role_sequence号将比ServerA的年夜1，由于发生了妨碍转移。这些信息唆使ServerA现在ServerB在ServerA只要承当了主服务器的脚色。ServerA和ServerB构成quorum并成为一对镜像，今后两台服务器坚持同步。除非ServerW恢复，不然不会发生主动妨碍转移。
注重：假如ServerW在ServerA和ServerB接踵以后也宣布失利，那末不管以甚么序次恢复见证服务器，已转换完成的ServerA和ServerB的脚色将坚持稳定。
场景HASL2.1：镜像服务器失利
假如镜像服务器起首失利，那末主服务器被视为exposed，由于它没法发送数据给镜像服务器。显现了ServerB，即镜像服务器失利时的举动。
：在高可用形式下，当镜像服务器ServerB失利时不发生妨碍转移
没有主动妨碍转移产生，镜像同伴也不会互换脚色。当ServerB恢复时，一切三台服务器复原到其初始脚色和形态。
下表显现了镜像服务器ServerB失利和恢复时数据库形态。
因为没有镜像服务器，数据没法寄存在冗余数据库中，因而会话处于exposed。
ServerB一旦恢复立即从头承当起它的镜像服务器脚色。只需两台服务器同步，镜像会话就不再被视为exposed。
接上去的两个场景思索镜像服务器ServerB失利，紧接着主服务器ServerA大概见证服务器ServerW失利时发生的了局。
场景HASL2.2：镜像服务器失利，随后主服务器失利
紧随镜像服务器以后主服务器也失利了，镜像同伴服务器的脚色坚持稳定。显现了接纳分歧体例复原服务器时脚色将怎样转换。
：镜像服务器失利随后主服务器主失利，那末见证服务器被伶仃
在ServerB和ServerA都失利后，各服务器形态显现在图中的右上角处。
假如ServerB起首恢复，它将从见证服务器ServerW处检测到ServerA仍然为主服务器而且还没有发生妨碍转移，mirroring_failover_lsn也没有增添。其了局为，ServerB仍然为镜像服务器。ServerW恢复后将会话复原到初始形态。
注重：假如ServerW在ServerB和ServerA接踵失利以后也宣布失利了，那末以任何按次复原这些服务器将招致不异了局。
场景HASL2.3：镜像服务器失利，随后见证服务器失利
镜像服务器失利，随后见证服务器也失利，那末主服务器被伶仃而且没法和任何其他服务器构成quorum。因而它必需中断数据库的事情，如右上角所示。
：A镜像服务器失利，随后见证服务器失利，招致主服务器没法供应数据库服务
因为镜像服务器妨碍和随后的见证服务器失利，主服务器ServerA坚持其主服务器脚色，因为没法和任何其他服务器构成quorum，而safety又被设置成FULL，因而不再为数据库供应服务，并断开一切的用户毗连。
假如ServerB起首恢复，那末数据库镜像将从头入手下手事情，只管因为缺掉见证服务器而不会发生主动妨碍转移。
假如ServerW起首恢复，那末情形与中显现的一样。
注重：假如ServerA在ServerB和ServerW接踵失利以后也宣布失利，那末以任何序次复原这些服务器其终极了局坚持稳定。
场景HASL3.1：见证服务器失利
见证服务器失利时，数据库镜像持续举行可是不成能发生主动的妨碍转移。假如再有一台或多台服务器失利，就意味着没法构成quorum，那末主服务器上的数据库也不再服务于数据库用户。
：在高可用形式下，见证服务器ServerW起首失利，那末数据库镜像持续
ServerW恢复后，两个同伴服务器ServerA和ServerB保持它们的初始脚色。
下表显现了见证服务器失利和恢复后，数据库形态和quorum的变更。
上面的两个场景思索见证服务器ServerW失利，紧接着主服务器ServerA大概镜像服务器ServerB失利时发生的了局。
场景HASL3.2：见证服务器失利，随后主服务器失利
见证服务器起首失利，那末数据库镜像将持续举行，可是不成能发生主动的妨碍转移。其他两台服务器中任何一台失利将招致没法构成quorum，余下的那台服务器将被伶仃。
：原始见证服务器失利，随后主服务器失利，镜像同伴脚色坚持稳定
假如ServerW起首恢复，那末ServerB将从见证服务器那边检测到最初的主服务器是ServerA，同时ServerB仍然是镜像服务器。终极ServerA恢复时，它将坚持其主服务器脚色。
注重：假如ServerB在ServerW和ServerA接踵失利后也宣布失利了，那末以恣意序次复原这些服务器都不会影响终极了局。
场景HASL3.3：见证服务器失利，随后镜像服务器失利
假如见证服务器失利，随后镜像服务器也失利，那末主服务器被伶仃。因为safety设置为FULL而且主服务器没法构成quorum，它将不再供应数据库服务，如0所示。
0：见证服务器失利，随后镜像服务器失利，主服务器必需中断其数据库服务
注重：假如ServerA在ServerW和ServerB接踵失利以后也宣布失利，那末以恣意序次复原这些服务器都不会影响终极了局。
总结：高可用处景中服务器失利
从这些场景中能够得出几个结论。在高可用操纵形式下：
1.假如主服务器起首不成用，那末发生主动的妨碍转移，本来的镜像服务器将承当主服务器脚色，并使其数据库服务于用户举动。后续的服务器失利和恢复不会影响利用新主服务器的数据库镜像的全体设置。数据库镜像将以相反的偏向持续举行。
2.假如镜像起首不成用，那末发生主动的妨碍转移。后续的服务器失利和恢复序次都不会影响镜像同伴脚色。
3.假如见证服务器起首不成用，那末不成能发生主动的妨碍转移，镜像同伴服务器将坚持其初始脚色。后续的服务器失利和恢复都不会影响镜像同伴脚色。
下表总结了在高可用处景中呈现一台或两台服务器失利时发生的了局。表中假定的前提是safety设置为FULL而且镜像会话中的服务器满意以下前提：
A：主服务器，SYNCHRONIZED
B：镜像服务器，SYNCHRONIZED
W：见证服务器，CONNECTED
表中利用灰色加亮显现妨碍转移场景。
表10：总结：单服务器大概双服务器失利，显现同伴服务器脚色和数据库形态
高可用处景中通讯失利
高可用操纵形式必要三个SQLSever实例。假如这些服务器位于两个或三个自力的物理站点而且相距很远，那末这些站点间的通讯就极可能呈现成绩。换句话说，服务器仍然运转可是相互间的通讯连路中止了。这类情形比后面的那些场景要庞大一些，但道理是一样的。
上面高可用操纵场景中通讯失利的研讨将经由过程两组来完成。第一组是基于三个来自分歧站点的SQLSERVER实例，因而有三条自力的通讯连路。第二组是基于两个自力站点上的服务器，第一个站点上的一对服务器和第二个站点上的第三台服务器之间有一条通讯连路。
先从第一组入手下手，假定一个数据库会话中一切三台服务器之间有三条自力的通讯连路。比方，主服务器、镜像服务器和见证服务器位于三个自力的合作站点上（也有大概三台服务器位于统一个站点，但利用公有收集毗连）
初始前提是ServerA上运转主数据库而且与其镜像同伴ServerB坚持同步。
ServerB上是镜像数据库Safety设置为FULL，见证服务器(ServerW)也包括在数据库镜像会话中。1显现了初始设置。
1：高可用设置中三台自力服务器、三条自力通讯连路的初始形态
注重：要取得页面上图表的注释，请参阅后面先容的“高可用处景中服务器失利”
依据1，三条链路大概起首中止：A/B，A/W和B/W。注重当某条通讯连路中止时，一切三台服务器仍然运转一般。只要主服务器和镜像服务器之间的通讯连路有一些影响，如表11所示。
表11：总结：单条通讯连路中止
初始前提
事务
Quorum
了局
前提
A：主服务器，SYNCHRONIZED
B：镜像服务器，SYNCHRONIZED
W：见证服务器，
CONNECTED
A/B连路中止
A和W
A上的数据库供应服务，exposed
A：主服务器，DISCONNECTED
B：镜像服务器， DISCONNECTED
W：见证服务器，
CONNECTED
A/W
A和B
A上的数据库供应服务
A：主服务器，SYNCHRONIZED
B：镜像服务器，SYNCHRONIZED
W：见证服务器，
CONNECTED
B/W
A和B
A上的数据库供应服务
A：主服务器，SYNCHRONIZED
B：镜像服务器，SYNCHRONIZED
W：见证服务器，
CONNECTED
只要主服务器/镜像服务器的毗连中止会对镜像形成影响。其他的连路中止，比方主服务器/见证服务器大概镜像服务器/见证服务器之间的通讯中止不会改动数据库镜像会话的举动。
总之，表HACL1显现出：
◆一切单条链路中止场景中只要主服务器/镜像服务器链路中止会影响数据库镜像，主服务器运转形态为exposed，由于没有日记纪录发送到镜像。
如今思索假如第二条连路中止发生的了局。两条连路能够同时中止，也能够接踵中止。
假如两条连路同时中止，其终极了局与两条连路接踵中止是一样的。可是没法事前意料中止的前后按次；只要晓得了前后序次才干够据此剖析链路同时中止的了局。
<p> 因为这个缘故原由，我们只思索链路按次中止的情况。表12列出了高可用形式中通讯链路中止的一些基础场景。 表12：年夜部分双-通讯链路中止的了局与服务器妨碍场景中单机妨碍是一样的
场景
第一条连路中止
场景
第一条连路中止
了局
其他服务器的等价场景
参阅场景
HACL1.1
A/B
HACL1.2
A/W
ServerA被伶仃
ServerA停机
无
HACL1.3
B/W
ServerB被伶仃
ServerB停机
HASL2.1
HACL2.1
A/W
HACL2.1
A/B
ServerA被伶仃
ServerA停机
HASL1.1
HACL2.2
B/W
ServerW被伶仃
ServerW停机
HASL3.1
HACL3.1
B/W
HACL3.1
A/W
ServerW被伶仃
ServerW停机
HASL3.1
HACL3.2
A/B
ServerB被伶仃
ServerB停机
HASL2.1
表HACL2显现一切按次的双-通讯链路失利都等价于前一部分先容的单服务器妨碍场景，因而我们不再这里对它们作反复剖析了。
值得注重的一点是：
◆两条链路中止时只要一个场景会发生妨碍转移：主服务器/见证服务器链路中止，随后主服务器/镜像服务器链路中止。
假如主服务器/镜像服务器链路中止，随后主服务器/见证服务器也呈现链路中止，那末不会发生妨碍转移，即便主服务器被伶仃并且镜像服务器和见证服务器没法接洽上它。
我们再细心研讨一了局景HACL1.2。
场景HACL1.2：主服务器/镜像服务器连路中止，随后主服务器/见证服务器链路中段
假如主服务器/镜像服务器链路中段，随后主服务器和见证服务器之间的链路也中止了，那末主服务器被伶仃。它看不到其他服务器而且得到了它的quorum。同时，镜像服务器和见证服务器没法晓得主服务器是不是仍然健在，因而ServerB承当起主服务器，然后主动的妨碍转移发生。2显现了这些事务。
2：在高可用形式下，主服务器/镜像服务器链路中段，随后主服务器/见证服务器链路中段，不发生妨碍转移
当主服务器/镜像服务器和主服务器/见证服务器之间的通讯链路接踵中止有，ServerA被伶仃并使其数据库中断服务。ServerB和W没法构成quorum，由于ServerA大概实行了一些ServerB上没有的事情。
假如主服务器/见证服务器(A/W)链路中止起首修复，那末ServerA持续承当其主服务器脚色，形态为DISCONNECTED。可是不会举行数据库镜像，由于主服务器和镜像服务器之间的毗连还没有修复。
假如主服务器/镜像服务器(A/B)链路中止起首修复，那末ServerA将持续与ServerB的数据库竞相，即便没有见证服务器，因而该会话是exposed。除非主服务器/见证服务器毗连终极被修复，不然不会发生主动的妨碍转移。
总结：高可用处景中通讯失利：三个站点
下表总结了利用三台自力物理服务器时单链路和双-链路中止的举动。
表中的初始前提是Safety设置为FULL，服务器分离是：
A：主服务器，SYNCHRONIZED
B：镜像服务器，SYNCHRONIZED
W：见证服务器，CONNECTED
利用灰色加亮显现妨碍转移路径。
表13：总结：单条链路中止和双-链路中止，高可用形式，三台自力服务器，Safety设置为FULL
场景HACL4：两个站点，见证服务器位于镜像服务器站点
假如一切服务器之间唯一一条通讯连路，那末必需选择见证服务器的地位。起首，假定见证服务器和镜像数据库服务器安排在一同。两组服务器之间唯一一条通讯连路，该链路大概中止，如3所示。
3：主服务器和镜像服务器/见证服务器站点之间的通讯连路中止了
ServerA看不到见证服务器ServerW大概镜像数据库服务器ServerB，因而没法构成quorum。ServerB和ServerW能够构成quorum，但两者均没法瞥见主服务器ServerA。链路中止的了局显现在4。
4：通讯连路中止而且见证服务器位于镜像服务器站点，发生妨碍转移
php本地模拟的prepare底层就是mysql_real_escape_string，所以必须得用mysql_set_character_set去设置mysql->charset，否则就存在字符集问题。 |
|
|Archiver|手机版|仓酷云
鄂ICP备14007578号-2
发表于 2015-1-16 22:17:12
收藏
转播
分享
淘帖
顶
踩
提升卡
置顶卡
沉默卡
喧嚣卡
变色卡
千斤顶
照妖镜
窥视卡
雷达卡
发表于 2015-3-7 00:27:47