复制管理和维护

Posted

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了复制管理和维护相关的知识,希望对你有一定的参考价值。

参考技术A 复制增加了mysql监控的复杂性。尽管复制发生在主库和备库上,但大多数工作是在备库上完成的,这也正是最常出问题的地方。是否所有的备库都在工作?最慢的备库延迟是多大? MySQL 本身提供了大量可以回答上述问题的信息,但要实现自动化监控过程以及使复制更健壮还是需要用户做更多的工作。

在主库上,可以使用SHOW MASTER STATUS命令来查看当前主库的二进制日志位置和配置。还可以查看主库当前有哪些二进制日志是在磁盘上的:

该命令用于给PURGE MASTER LOGS命令决定使用哪个参数。另外还可以通过SHOW BINLOG EVENTS 来查看复制事件。例如,在运行前一个命令后,我们在另一个不曾使用 过的服务器.上创建一个表,因为知道这是唯一改变数据的语句,而且也知道语句在二进制日志中的偏移量是13634,所以我们可以看到如下内容:

一个比较普遍的问题是如何监控备库落后主库的延迟有多大。虽然SHOW SLAVE STATUS 输出的Seconds_ behind_ master列理论上显示了备库的延时,但由于各种各样的原因, 并不总是准确的:

解决这些问题的办法是忽略Seconds_behind_master 的值,并使用-些可以直接观察和 衡量的方式来监控备库延迟。最好的解决办法是使用heartbeat record,这是-一个在主库上会每秒更新一次的时间戳。为了计算延时,可以直接用备库当前的时间戳减去心跳记录的值。这个方法能够解决刚刚我们提到的所有问题,另外一个额外的好处是我们还可以通过时间戳知道备库当前的复制状况。包含在PerconaToolkit里的pt-heartbeat脚本是“复制心跳”最流行的一种实现。

心跳还有其他好处,记录在二进制日志中的心跳记录拥有许多用途,例如在一些很难解决的场景下可以用于灾难恢复。

刚刚所描述的几种延迟指标都不能表明备库需要多长时间才能赶上主库。这依赖于许多因素,例如备库的写入能力以及主库持续写入的次数。

在理想情况下,备库和主库的数据应该是完全一样的。但事实上备库可能发生错误并导致数据不一致。即使没有明显的错误,备库同样可能因为MySQL自身的特性导致数据不一致,例如MySQL的Bug网络中断、服务器崩溃,非正常关闭或者其他一些错误。

按照经验来看,主备一致应该是一种规范,而不是例外,也就是说,检查你的主备一致性应该是一个日常工作,特别是当使用备库来做备份时尤为重要,因为你肯定不希望从一个已经损坏的备库里获得备份数据。

MySQL并没有内建的方法来比较一台服务器与别的服务器的数据是否相同。它提供了一些组件来为表和数据生成校验值,例如CHECKSUM TABLE。 但当复制正在进行时,这种方法是不可行的。

Percona Toolkit 里的pt-table-checksum能够解决上述几个问题。其主要特性是用于确认 备库与主库的数据是否一致。工作方式是通过在主库上执行INSERT.. .SELECT查询。

这些查询对数据进行校验并将结果插人到一个表中。这些语句通过复制传递到备库,并在备库执行一遍,然后可以比较主备上的结果是否一样。由于该方法是通过复制工作的, 它能够给出一致的结果而无须同时把主备上的表都锁上。

通常情况下可以在主库上运行该工具,参数如下:

该命令将检查所有的表,并将结果插入到test. checksum表中。当查询在备库执行完后,就可以简单地比较主备之间的不同了。pt-table-checksum能够发现服务器所有的备库,在每台备库上运行查询,并自动地输出结果。

在你的职业生涯中,也许会不止一次需要去处理未被同步的备库。可能是使用校验工具发现了数据不一致,或是因为已经知道是备库忽略了某条查询或者有人在备库上修改了数据。

传统的修复不一致的办法是关闭备库,然后重新从主库复制一份数据。当备库数据不一致的问题可能导致严重后果时,一旦发现就应该将备库停止并从生产环境移除,然后再从一个备份中克隆或恢复备库。

这种方法的缺点是不太方便,特别是数据量很大时。如果能够找出并修复不一致的数据, 要比从其他服务器上重新克隆数据要有效得多。如果发现的不一致并不严重,就可以保持备库在线,并重新同步受影响的数据。

最简单的办法是使用mysqldump转储受影响的数据并重新导入。在整个过程中,如果数据没有发生变化,这种方法会很好。你可以在主库上简单地锁住表然后进行转储,再等待备库赶上主库,然后将数据导人到备库中。(需要等待备库赶上主库,这样就不至于为其他表引人新的不一致,例如那些可能通过和失去同步的表做join后进行数据更新的表)。

虽然这种方法在许多场景下是可行的,但在一个繁忙的服务器上有可能行不通。另外一个缺点是在备库上通过非复制的方式改变数据。通过复制改变备库数据(通过在主库上执行更新)通常是一种安全的技术,因为它避免了竞争条件和其他意料外的事情。如果表很大或者网络带宽受限,转储和重载数据的代价依然很高。当在一个有一百万行的表上只有一千行不同的数据呢?转储和重载表的数据是非常浪费资源的。

pt-table-sync是Percona Toolkit中的另外一个工具,可以解决该问题。该工具能够高效地查找并解决表之间的不同。它同样通过复制工作,在主库上执行查询,在备库上重新同步,这样就没有竞争条件。它是结合pt-table-checksum生成的checksum表来工作的, 所以只能操作那些已知不同步的表的数据块。但该工具不是在所有场景下都有效。为了正确地同步主库和备库,该工具要求复制是正常的,否则就无法工作。pt-table-sync设计得很高效,但当数据量非常大时效率还是会很低。比较主库和备库上1TB的数据不可避免地会带来额外的工作。尽管如此,在那些合适的场景中,该工具依然能节约大量的时间和工作。

如果有备库和新主库的位置不相同,则需要找到该备库最后--条执行的事件在新主库的 二进制日志中相应的位置,然后再执行CHANGE MASTER T0。 可以通过mysqlbinlog工具 来找到备库执行的最后一条查询,然后在主库上找到同样的查询,进行简单的计算即可得到。

为了便于描述,假设每个日志事件有一个自增的数字ID,最新的备库,也就是新主库,在旧主库崩溃时获得了编号为100的事件,假设有另外两台备库: replica2和 replica3。replica2已经获取了99号事件,replica3 获取了98号事件。如果把两台备库都指向新主库的同一个二进制日志位置,它们将从101号事件开始复制,从而导致数据不同步。但只要新主库的进制日志已经通过log_slave_updates 打开,就可以在新主库的二进制日志中找到99号和100号日志,从而将备库恢复到一致的状态。

由于服务器重启,不同的配置,日志轮转或者FLUSH LOGS 命令,同一个事件在不同的服务器上可能有不同的偏移量。找到这些事件可能会耗时很长并且枯燥,但是通常没有难度。通过mysqlbinlog从二进制日志或中继日志中解析出每台备库上执行的最后一个事件, 并同样使用该命令解析新主库上的二进制日志,找到相同的查询,mysqlbinlog会打印出该事件的偏移量,在CHANGE MASTER T0命令中使用这个值。

更快的方法是把新主库和停止的备库上的字节偏移量相减,它显示了字节位置的差异。 然后把这个值和新主库当前二进制日志的位置相减,就可以得到期望的查询的位置。只需要验证一下就可以据此启动备库。

让我们看看一个相关的例子,假设server1是server2和server3的主库,其中服务器 server1已经崩溃。根据SHOW SLAVE STATUS 获得Master_Log_File/Read Master_Log_Pos的值,server2 已经执行完了server1 上所有的二进制日志,但server3还不是最新数据。下图显示了这个场景(日志事件和偏移量仅仅是为了举例)。

正如上图所示,我们可以肯定server2已经执行完了主库上的所有二进制日志,因 为Master_Log_File和Read_Master_Log_Pos值和server1上最后的日志位置是相吻合的,因此我们可以将server2提升为新主库,并将server3设置为server2的备库。

应该在server3上为需要执行的CHANGE MASTER TO语句赋予什么样的参数呢?这里需要 做一点点计算和调查。server3 在偏移量1493停止,比server2执行的最后一条语句的偏移量1582要小89字节。server2 正在向偏移量为8167的二进制日志写入,8167-89=8078,因此理论上我们应该将server3指向server2的日志的偏移量为8078的位置。最好去确认下这个位置附近的日志事件,以确定在该位置上是否是正确的日志事件,因为可能有别的例外,例如有些更新可能只发生在server2上。

假设我们观察到的事件是--样的,下面这条命令会将server3切换为server2的备库。

如果服务器在它崩溃时已经执行完成并记录了超过一个事件,会怎么样呢?因为 server2仅仅读取并执行到了偏移位置1582,你可能永远地失去了一个事件。但是如果老主库的磁盘没有损坏,仍然可以通过mysqlbinlog或者从日志服务器的二进制日志中找到丢失的事件。

如果需要从老主库上恢复丢失的事件,建议在提升新主库之后且在允许客户端连接之前做这件事情。这样就无须在每台备库上都执行丢失的事件,只需使用复制来完成。但如果崩溃的老主库完全不可用,就不得不等待,稍后再做这项工作。

Windows Server 2016-域站点复制查询

了解了有关站点复制概念性内容后,后续几章节我们会围绕站点复制相关内容对域控的日常复制、维护等进行简单介绍。本章为大家带来有关域控站点复制查询的相关内容,希望大家可以喜欢。站点内域控制器之间的复制拓扑由KCC自动生成,站点间域控制器复制拓扑由ISTG自动生成。如果域控制器数量较少且在一个站点内,建议由KCC自动管理复制拓扑。如果多站点管理,建议站点中使用一台高性能的桥头堡服务器和其他站点链接,或者由ISTG自动生成,复制环境中尽量减少域管理员手动参与,并保证网络环节畅通。复制建议通过"Active Directory站点和服务"管理。

1.查询域内站点信息:dsquery site

技术分享图片

有关dsquery命令行帮忙信息如下:
C:\> dsquery /?
描述: 该工具的命令集允许你根据指定的标准查询目录。
除 dsquery * 之外 (dsquery * 可以查询任何类型的对象),以下每一个 dsquery 命令均可查找一个特定对象类型:
dsquery computer - 查找目录中的计算机。
dsquery contact - 查找目录中的联系人。
dsquery subnet - 查找目录中的子网。
dsquery group - 查找目录中的组。
dsquery ou - 查找目录中的组织单位。
dsquery site - 查找目录中的站点。
dsquery server - 查找目录中的 AD DC/LDS 实例。
dsquery user - 查找目录中的用户。
dsquery quota - 查找目录中的配额规定。
dsquery partition - 查找目录中的分区。
dsquery * - 用通用的 LDAP 查询来查找目录中的任何对象。
若要查找特定命令的帮助,请键入 "dsquery <ObjectType> /?",其中<ObjectType> 是以上所示的受支持对象类型之一。
dsquery site 
在目录中查找与指定的搜索条件相匹配的站点。如果该命令中预定义的搜索条件不充分,可以使用该查询命令的更常规的形式 dsquery *。
语法:
dsquery site [-o {dn | rdn}] [-name Name] [-desc Description] [{-s Server| -d Domain}] [-u UserName] [-p {Password|*}] [-q] [-r] [-gc] [-limit NumberOfObjects] [{-uc | -uco | -uci}]
参数
-o {dn | rdn}指定搜索所找到的条目列表的显示格式。值 dn 显示每个条目的可分辨名称。值 rdn 显示每个条目的相对可分辨名称。
-name Name 搜索其名称属性(CN 属性的值)与 Name 相匹配的站点。例如"NA*"或"Europe*"。
-desc Description 搜索其描述属性与 Description 相匹配的计算机。例如"corp*"或"*nch"。
{-s Server| -d Domain} 连接到指定远程服务器或域。默认情况下,计算机与登录域中的域控制器相连接。
-u UserName 指定用户用以登录远程服务器的用户名。默认情况下,-u 使用用户登录时的用户名。您可以使用下列任何一种格式指定用户名:
用户名(例如 Linda)
域\用户名(例如 widgets\Linda)
用户主体名称 (UPN)(例如 [email protected])
-p {Password | *} 指定使用密码还是 * 登录到远程服务器。如果键入 *,系统将提示输入密码。
-q 取消到标准输出的所有输出(安静模式)。
-r 指定搜索期间搜索将使用递归或跟踪参照。默认情况下,在搜索期间搜索将不跟踪参照。
-gc 指定搜索使用 Active Directory 全局编录。
-limit NumberOfObjects 指定将返回与给定条件匹配的对象的个数。如果 NumberOfObjects 的值为 0,则返回所有匹配的对象。如果未指定该参数,则默认显示前 100 条结果。
{-uc | -uco | -uci} 指定以 Unicode 格式输出或输入数据。下表列出并描述了每一种格式。
-uc 为从管道 (|) 输入或输出到管道 (|) 指定 Unicode 格式。
-uco 指定以 Unicode 格式输出到管道 (|) 或文件。
-uci 指定以 Unicode 格式从管道 (|) 或文件输入。

2.查询站点中所有域控制器:dsquery server –site <站点名称>

技术分享图片

3.查询域控制器站点间拓扑生成器(ISTG)服务器信息:repadmin /istg

技术分享图片

repadmin istg
为指定站点返回站点间拓扑生成器 (ISTG) 服务器的计算机名。
语法
repadmin /istg [dsa] [/verbose]
参数
Dsa 指定一个目录服务器。有关 dsa 参数的详细信息,请参阅常规参数。
/verbose 列出详细信息。

4.强制同步复制两台域控制器信息:repadmin /replicate 域A 域B dc=*,dc=com /force

技术分享图片

PS C:\> repadmin /?
用法: repadmin <cmd> <args> [/u:{domain\user}] [/pw:{password|*}] [/retry[:<retries>][:<delay>]] [/csv]
使用下列命令查看帮助:
/? 显示 repadmin 中可以使用的一系列命令及其说明。
/help 与 /? 相同。
/?:<cmd> 显示特定命令 <cmd> 的可用参数 <args>、相应语法以及示例的列表。/help:<cmd> 与 /?:<cmd> 相同
/experthelp 显示仅供高级用户使用的一系列命令。
/listhelp 显示可用于 DSA_NAME、DSA_LIST、NCNAME 和 OBJ_LIST 字符串的语法变量。
/oldhelp 显示一系列不推荐使用的命令,这些命令仍然有效,但 Microsoft已不再支持它们。
支持的 <cmd> 命令(使用 /?<cmd> 获取详细帮助):
/kcc 强制目标域控制器上的 KCC 立即重新计算其入站复制拓扑。
/prp 该命令允许管理员查看或修改 RODC 的密码复制策略。
/queue 显示 DC 要与其源复制伙伴一致所需发布的入站复制请求。
/replicate 触发将指定的目录分区立即从源 DC 复制到目标域控制器。
/replsingleobj 在具有公共目录分区的任何两个域控制器之间复制单个对象。
/replsummary replsummary 操作快速简明地概述林的复制状态和相对健康状况。
/rodcpwdrepl 触发将指定用户的密码从源(集线器 DC)复制到一个或多个只读 DC。
/showattr 显示对象的属性。
/showobjmeta 显示存储在 Active Directory 中的指定对象的复制元数据,如属性 ID、版本号、原始和本地更新序列号(USN)、原始服务器的 GUID以及日期和时间戳。
/showrepl 当指定的域控制器上次尝试入站复制 Active Directory 分区时显示复制状态。
/showutdvec 显示提交的最高更新序列号(USN),其中 Active Directory 的目标 DC 副本
显示为其自身以及其可传递伙伴的提交。
/syncall 将指定的域控制器与所有复制伙伴同步。
支持的其他参数:
/u: 指定用反斜杠分隔的域和用户名 {domain\user},该用户具有在 Active Directory 中执行操作的权限。不支持 UPN 登录。
/pw: 指定用于通过 /u 参数输入的用户名的密码。
/retry 当 repadmin 绑定到目标 DC 的首次尝试失败并返回下列错误状态信息时,此参数可以促使其重复其绑定操作: 1722 / 0x6ba : "RPC 服务器不可用" 1753 / 0x6d9 : "终结点映射器中再也没有可用的终结点"
/csv 与 /showrepl 一起使用输出逗号分隔数值格式的结果。

技术分享图片

5.查询域控制器间复制信息:repadmin /showrepl

技术分享图片

6.同步域控制器信息: repadmin /syncall

强制同步域控制器信息: repadmin /syncall /force

同步想领域控制器信息: repadmin /syncall /j

技术分享图片

repadmin syncall
使指定的目录服务器与所有复制伙伴同步。此命令包含几个子命令
语法
repadmin /syncall dsa [NamingContext] [Flags]
参数
dsa指定一个目录服务器。
NamingContext指定目录分区的可分辨名称。
标志在复制过程中执行特定操作,如下所示。
标志    描述
/a 如果任何服务器均不可用,则中止。
/A 使 dsa 所代表的目录服务器中的所有目录分区同步。
/d 按消息中的可分辨名称(而不是 GUID DNS)确定服务器。
/e 跨所有站点同步目录分区。(默认行为是仅同步在 dsa 所代表的目录服务器所在站点中的目录分区。)
/h 显示 repadmin /syncall 的帮助。
/i 无限期地重复。
/I 在路径中每个目录服务器对上执行 repadmin /showrepl,不执行同步操作。
/j 只同步相邻的目录服务器。
/p 每条消息后暂停,以便让用户有机会中止操作。
/P 从 dsa 所代表的目录服务器向外推出 (push) 更改。(该命令的默认行为是拉进 (pull) 更改,而不是推出 (push) 更改。)
/q 以安静模式运行;取消回拨 (callback) 消息。
/Q 以非常安静模式运行;只报告致命错误。
/s 执行拓扑分析并生成消息,但不同步目录分区。

7.显示域控制器之间复制数量和状态:repadmin /replsum

技术分享图片

本章分享就到这里了,感谢支持。

以上是关于复制管理和维护的主要内容,如果未能解决你的问题,请参考以下文章

MySQL复制日常维护与管理

MongoDB复制集部署和基本管理

MongoDB 复制集

大数据 MongoDB 复制集管理

MongoDB复制集选举原理管理

Windows Server 2016-域站点复制查询