关于Segment恢复处理
关于Segment恢复处理
这个主题描述由gprecoverseg管理工具发起的Segment恢复过程。它描述gprecoverseg执行的动作以及Greenplum的文件复制和FTS(容错服务)进程如何完成用gprecoverseg发起的恢复。
尽管gprecoverseg是一种在线操作,但其中有两个很短暂的时段所有的I/O都会被暂停。首先,当恢复开始时,在镜像上创建空数据文件时IO会被暂停。其次,在数据文件被同步后,从主Segment向镜像复制系统文件(例如事务日志)时会暂停IO。这些暂停的长短主要受到必须在镜像上复制的文件系统文件数目以及必须被复制的系统平面文件尺寸影响。在数据库表从主Segment复制到镜像的过程中,系统处于在线和可用的状态,恢复期间对数据库做的任何更改都会被直接复制到镜像。
要开始恢复,管理员要运行gprecoverseg工具。gprecoverseg会为恢复准备Segment并且开始进行同步。当同步完成并且Segment的状态在系统目录中被更新后,Segment被恢复完成。如果被恢复的Segment没有运行在它们的首选角色下,可以用gprecoverseg -r让系统重新恢复平衡。
如果没有-F选项,gprecoverseg会增量地恢复Segment,只复制从镜像进入到down状态以来发生的更改。通过删除镜像的数据目录并且接着从主Segment同步所有持久数据文件到镜像,-F选项可以完全恢复镜像。
在恢复处理之前和期间,可以运行gpstate -e来查看Segment的镜像状态。主Segment和镜像Segment的状态会在恢复处理进行中被更新。
考虑一对主Segment和镜像Segment,其中主Segment处于活动状态而镜像Segment处于down的状态。下面的表展示了镜像恢复开始前Segment的状态。
首选角色 | 当前角色 | 模式 | 状态 | |
---|---|---|---|---|
主Segment |
p (主) |
p (主) |
c (改变跟踪) |
u (up) |
镜像Segment |
m (镜像) |
m (镜像) |
s (同步中) |
d (down) |
这些Segment都处于它们的优先角色,但镜像Segment处于宕机状态。主Segment已启动并且处于改变跟踪模式,因为它无法把改变发送到它的镜像。
Segment恢复准备
gprecoverseg工具为恢复操作准备好Segment然后退出,允许Greenplum的文件复制进程从主Segment复制数据到镜像。
在gprecoverseg执行期间会完成下列处理步骤。
- 标识出宕机的Segment。
- 初始化镜像Segment进程。
- 对于完全恢复(-aF):
- 宕机的Segment的数据目录会被删除。
- 创建一个新的数据目录。
- gp_segment_configuration系统表中的Segment模式被更新为'r'(重新同步模式)。
- 后台会执行下面这些:
- 允许到Master的被禁止的IO连接,但是不允许来自被恢复Segment的读写。
- 在主Segment上扫描持久化的表。
- 对于每个持久化文件对象(pg_class系统表中的relfilenode),在镜像上创建一个数据文件。
数据文件的数量越大,IO被暂停的时间越长。
对于增量恢复,IO会被暂停一段更短的时段,因为只有在该镜像被标记为宕机之后在主Segment上增加(或者删除)的文件系统对象才需要在镜像上创建(或者删除)。
- gprecoverseg脚本完成。
一旦gprecoverseg已经完成,Segment就处于下表所展示的状态。
首选角色 | 当前角色 | 模式 | 状态 | |
---|---|---|---|---|
主 |
p (主) |
p (主) |
r (重新同步中) |
u (up) |
镜像 |
m (镜像) |
m (镜像) |
r (重新同步中) |
u (up) |
数据文件复制
文件复制进程会在后台执行数据文件的重新同步。运行gpstate -e可以检查重新同步的进展。在这一处理完成后,Greenplum系统进入到对负载完全可用的状态。
在重新同步过程中遵照以下步骤:
-
数据拷贝(完全恢复和增量恢复):
在文件系统对象被创建后,会为受影响的Segment开始数据拷贝。ResyncManager进程扫描持久化表系统目录来寻找要被同步的文件对象。ResyncWorker进程把那些文件对象从主Segment同步到镜像Segment。
- 在数据拷贝期间数据库事务所作的任何改变或者创建的新数据会被直接镜像到镜像Segment。
- 一旦数据拷贝完成了同步持久化数据文件,文件复制会把当前主Segment上的共享内存状态更新为'insync'。
平面文件复制
- pg_xlog/*
- pg_clog/*
- pg_distributedlog/*
- pg_distributedxidmap/*
- pg_multixact/members
- pg_multixact/offsets
- pg_twophase/*
- global/pg_database
- global/pg_auth
- global/pg_auth_time_constraint
这些文件被拷贝后,IOSUSPEND结束。
在Master上的容错服务器(ftsprobe)进程下一次苏醒时,它将把主Segment和镜像Segment的状态设置为同步(mode=s, state=u)。一次分布式查询也将会触发ftsprobe去更新该状态。
当所有Segment恢复和文件复制处理完成后,gp_segment_configuration系统表和gp_state -e的输出中的Segment状态如下表所示。
首选角色 | 当前角色 | 模式 | 状态 | |
---|---|---|---|---|
主 |
p (主) |
p (主) |
s (已同步) |
u (up) |
镜像 |
m (镜像) |
m (镜像) |
s (已同步) |
u (up) |
影响Segment恢复的因素
下面是一些能影响Segment恢复过程的因素。
- 数据库对象的数量,主要是表和索引。
- Segment数据目录中的数据文件数量。
- 在重新同步期间更新数据的负载类型 -- DDL和DML(插入、更新、删除和截断)。
- 数据的尺寸。
- 系统文件的尺寸,例如事务日志文件、pg_database、pg_auth和pg_auth_time_constraint。