Tabla de contenido
Dos, la tabla del sistema gp_segment_configuration
2.1 Enumere los nodos que están actualmente fuera de línea
2.2 Enumere la cantidad de nodos que se ejecutan en cada servidor del clúster
3. Recuperación y reequilibrio de fallos de segmento
Uno, gpstate
gpstate es un comando básico para comprender el estado de Greenplum. Puede usar este comando para obtener la información de estado de la base de datos actual independientemente de si la base de datos se está ejecutando normalmente.
Si ingresar el comando gpstate en la terminal no funciona, se recomienda verificar lo siguiente:
❏Si se ha ejecutado la fuente <directorio de instalación de Greenplum> /greenplum_path.sh.
❏ Si las variables de entorno MASTER_DATA_DIRECTORY y PGPORT están configuradas correctamente.
1.1 gpstate -s
Muestra información detallada de configuración y estado de cada nodo
~]$ gpstate -s
20210222:17:15:51:055081 gpstate:gpmaster:gpadmin-[INFO]:-Starting gpstate with args: -s
20210222:17:15:51:055081 gpstate:gpmaster:gpadmin-[INFO]:-local Greenplum Version: 'postgres (Greenplum Database) 6.7.0 build commit:2fbc274bc15a19b5de3c6e44ad5073464cd4f47b'
20210222:17:15:51:055081 gpstate:gpmaster:gpadmin-[INFO]:-master Greenplum Version: 'PostgreSQL 9.4.24 (Greenplum Database 6.7.0 build commit:2fbc274bc15a19b5de3c6e44ad5073464cd4f47b) on x86_64-unknown-linux-gnu, compiled by gcc (GCC) 6.4.0, 64-bit compiled on Apr 16 2020 02:24:06'
20210222:17:15:51:055081 gpstate:gpmaster:gpadmin-[INFO]:-Obtaining Segment details from master...
20210222:17:15:51:055081 gpstate:gpmaster:gpadmin-[INFO]:-Gathering data from segments...
20210222:17:15:52:055081 gpstate:gpmaster:gpadmin-[INFO]:-----------------------------------------------------
20210222:17:15:52:055081 gpstate:gpmaster:gpadmin-[INFO]:--Master Configuration & Status
20210222:17:15:52:055081 gpstate:gpmaster:gpadmin-[INFO]:-----------------------------------------------------
20210222:17:15:52:055081 gpstate:gpmaster:gpadmin-[INFO]:- Master host = gpmaster
20210222:17:15:52:055081 gpstate:gpmaster:gpadmin-[INFO]:- Master postgres process ID = 25885
20210222:17:15:52:055081 gpstate:gpmaster:gpadmin-[INFO]:- Master data directory = /greenplum/gpdata/master/gpseg-1
20210222:17:15:52:055081 gpstate:gpmaster:gpadmin-[INFO]:- Master port = 5432
20210222:17:15:52:055081 gpstate:gpmaster:gpadmin-[INFO]:- Master current role = dispatch
20210222:17:15:52:055081 gpstate:gpmaster:gpadmin-[INFO]:- Greenplum initsystem version = 6.7.0 build commit:2fbc274bc15a19b5de3c6e44ad5073464cd4f47b
20210222:17:15:52:055081 gpstate:gpmaster:gpadmin-[INFO]:- Greenplum current version = PostgreSQL 9.4.24 (Greenplum Database 6.7.0 build commit:2fbc274bc15a19b5de3c6e44ad5073464cd4f47b) on x86_64-unknown-linux-gnu, compiled by gcc (GCC) 6.4.0, 64-bit compiled on Apr 16 2020 02:24:06
20210222:17:15:52:055081 gpstate:gpmaster:gpadmin-[INFO]:- Postgres version = 9.4.24
20210222:17:15:52:055081 gpstate:gpmaster:gpadmin-[INFO]:- Master standby = No master standby configured
20210222:17:15:52:055081 gpstate:gpmaster:gpadmin-[INFO]:-----------------------------------------------------
20210222:17:15:52:055081 gpstate:gpmaster:gpadmin-[INFO]:-Segment Instance Status Report
20210222:17:15:52:055081 gpstate:gpmaster:gpadmin-[INFO]:-----------------------------------------------------
20210222:17:15:52:055081 gpstate:gpmaster:gpadmin-[INFO]:- Segment Info
20210222:17:15:52:055081 gpstate:gpmaster:gpadmin-[INFO]:- Hostname = gpseg01
20210222:17:15:52:055081 gpstate:gpmaster:gpadmin-[INFO]:- Address = gpseg01
20210222:17:15:52:055081 gpstate:gpmaster:gpadmin-[INFO]:- Datadir = /greenplum/gpdata/primary/gpseg0
20210222:17:15:52:055081 gpstate:gpmaster:gpadmin-[INFO]:- Port = 55000
20210222:17:15:52:055081 gpstate:gpmaster:gpadmin-[INFO]:- Mirroring Info
20210222:17:15:52:055081 gpstate:gpmaster:gpadmin-[INFO]:- Current role = Primary
20210222:17:15:52:055081 gpstate:gpmaster:gpadmin-[INFO]:- Preferred role = Primary
20210222:17:15:52:055081 gpstate:gpmaster:gpadmin-[INFO]:- Mirror status = Synchronized
20210222:17:15:52:055081 gpstate:gpmaster:gpadmin-[INFO]:- Status
20210222:17:15:52:055081 gpstate:gpmaster:gpadmin-[INFO]:- PID = 24988
20210222:17:15:52:055081 gpstate:gpmaster:gpadmin-[INFO]:- Configuration reports status as = Up
20210222:17:15:52:055081 gpstate:gpmaster:gpadmin-[INFO]:- Database status = Up
1.2 gpstate -e
Verifique el estado de todos los segmentos para ver si hay estados anormales como fuera de línea, recuperando datos, desequilibrados, etc.
~]$ gpstate -e
20210222:17:17:03:055291 gpstate:gpmaster:gpadmin-[INFO]:-Starting gpstate with args: -e
20210222:17:17:03:055291 gpstate:gpmaster:gpadmin-[INFO]:-local Greenplum Version: 'postgres (Greenplum Database) 6.7.0 build commit:2fbc274bc15a19b5de3c6e44ad5073464cd4f47b'
20210222:17:17:03:055291 gpstate:gpmaster:gpadmin-[INFO]:-master Greenplum Version: 'PostgreSQL 9.4.24 (Greenplum Database 6.7.0 build commit:2fbc274bc15a19b5de3c6e44ad5073464cd4f47b) on x86_64-unknown-linux-gnu, compiled by gcc (GCC) 6.4.0, 64-bit compiled on Apr 16 2020 02:24:06'
20210222:17:17:03:055291 gpstate:gpmaster:gpadmin-[INFO]:-Obtaining Segment details from master...
20210222:17:17:03:055291 gpstate:gpmaster:gpadmin-[INFO]:-Gathering data from segments...
20210222:17:17:03:055291 gpstate:gpmaster:gpadmin-[INFO]:-----------------------------------------------------
20210222:17:17:03:055291 gpstate:gpmaster:gpadmin-[INFO]:-Segment Mirroring Status Report
20210222:17:17:03:055291 gpstate:gpmaster:gpadmin-[INFO]:-----------------------------------------------------
20210222:17:17:03:055291 gpstate:gpmaster:gpadmin-[INFO]:-All segments are running normally
1.3 gpstate -Q
Verifique y enumere rápidamente la información de los nodos fuera de línea
1.4 gpstate -m
Enumere la información de configuración de todos los segmentos espejo
1.5 gpstate -f
Mostrar información sobre el nodo maestro en espera
~]$gpstate -f
20210222:17:20:15:033853 gpstate:P1QMSMDW01:gpadmin-[INFO]:-Starting gpstate with args: -f
20210222:17:20:15:033853 gpstate:P1QMSMDW01:gpadmin-[INFO]:-local Greenplum Version: 'postgres (Greenplum Database) 4.3.27.0 build 1'
20210222:17:20:15:033853 gpstate:P1QMSMDW01:gpadmin-[INFO]:-master Greenplum Version: 'PostgreSQL 8.2.15 (Greenplum Database 4.3.27.0 build 1) on x86_64-unknown-linux-gnu, compiled by GCC gcc (GCC) 4.4.2 compiled on Jul 11 2018 19:48:18'
20210222:17:20:15:033853 gpstate:P1QMSMDW01:gpadmin-[INFO]:-Obtaining Segment details from master...
20210222:17:20:16:033853 gpstate:P1QMSMDW01:gpadmin-[INFO]:-Standby master details
20210222:17:20:16:033853 gpstate:P1QMSMDW01:gpadmin-[INFO]:-----------------------
20210222:17:20:16:033853 gpstate:P1QMSMDW01:gpadmin-[INFO]:- Standby address = P1QMSMDW02
20210222:17:20:16:033853 gpstate:P1QMSMDW01:gpadmin-[INFO]:- Standby data directory = /gpmaster/gpseg-1
20210222:17:20:16:033853 gpstate:P1QMSMDW01:gpadmin-[INFO]:- Standby port = 5432
20210222:17:20:16:033853 gpstate:P1QMSMDW01:gpadmin-[INFO]:- Standby PID = 25445
20210222:17:20:16:033853 gpstate:P1QMSMDW01:gpadmin-[INFO]:- Standby status = Standby host passive
20210222:17:20:16:033853 gpstate:P1QMSMDW01:gpadmin-[INFO]:--------------------------------------------------------------
20210222:17:20:16:033853 gpstate:P1QMSMDW01:gpadmin-[INFO]:--pg_stat_replication
20210222:17:20:16:033853 gpstate:P1QMSMDW01:gpadmin-[INFO]:--------------------------------------------------------------
20210222:17:20:16:033853 gpstate:P1QMSMDW01:gpadmin-[INFO]:--WAL Sender State: streaming
20210222:17:20:16:033853 gpstate:P1QMSMDW01:gpadmin-[INFO]:--Sync state: sync
20210222:17:20:16:033853 gpstate:P1QMSMDW01:gpadmin-[INFO]:--Sent Location: 6CC/7ABFAA50
20210222:17:20:16:033853 gpstate:P1QMSMDW01:gpadmin-[INFO]:--Flush Location: 6CC/7ABFAA50
20210222:17:20:16:033853 gpstate:P1QMSMDW01:gpadmin-[INFO]:--Replay Location: 6CC/7ABEDFA8
20210222:17:20:16:033853 gpstate:P1QMSMDW01:gpadmin-[INFO]:--------------------------------------------------------------
1.6 gpstate -i
Mostrar información de la versión de Greenplum
~]$ gpstate -i
20210222:17:20:22:055731 gpstate:gpmaster:gpadmin-[INFO]:-Starting gpstate with args: -i
20210222:17:20:22:055731 gpstate:gpmaster:gpadmin-[INFO]:-local Greenplum Version: 'postgres (Greenplum Database) 6.7.0 build commit:2fbc274bc15a19b5de3c6e44ad5073464cd4f47b'
20210222:17:20:22:055731 gpstate:gpmaster:gpadmin-[INFO]:-master Greenplum Version: 'PostgreSQL 9.4.24 (Greenplum Database 6.7.0 build commit:2fbc274bc15a19b5de3c6e44ad5073464cd4f47b) on x86_64-unknown-linux-gnu, compiled by gcc (GCC) 6.4.0, 64-bit compiled on Apr 16 2020 02:24:06'
20210222:17:20:22:055731 gpstate:gpmaster:gpadmin-[INFO]:-Obtaining Segment details from master...
20210222:17:20:22:055731 gpstate:gpmaster:gpadmin-[INFO]:-Loading version information
20210222:17:20:22:055731 gpstate:gpmaster:gpadmin-[INFO]:- Host Datadir Port Version
20210222:17:20:22:055731 gpstate:gpmaster:gpadmin-[INFO]:- gpmaster /greenplum/gpdata/master/gpseg-1 5432 PostgreSQL 9.4.24 (Greenplum Database 6.7.0 build commit:2fbc274bc15a19b5de3c6e44ad5073464cd4f47b) on x86_64-unknown-linux-gnu, compiled by gcc (GCC) 6.4.0, 64-bit compiled on Apr 16 2020 02:24:06
Dos, la tabla del sistema gp_segment_configuration
Cuando el clúster de Greenplum está funcionando, puede consultar gp_segment_configuration para obtener la configuración y el estado de ejecución de todos los nodos. gp_segment_configuration se encuentra en el espacio de tabla pg_global, sin importar a qué nombre de base de datos esté conectado el cliente SQL actual, se puede consultar la tabla del sistema.
postgres=# select * from gp_segment_configuration;
dbid | content | role | preferred_role | mode | status | port | hostname | address | datadir
------+---------+------+----------------+------+--------+-------+----------+----------+----------------------------------
1 | -1 | p | p | n | u | 5432 | gpmaster | gpmaster | /greenplum/gpdata/master/gpseg-1
5 | 3 | p | p | s | u | 55000 | gpseg02 | gpseg02 | /greenplum/gpdata/primary/gpseg3
11 | 3 | m | m | s | u | 56000 | gpseg01 | gpseg01 | /greenplum/gpdata/mirror/gpseg3
6 | 4 | p | p | s | u | 55001 | gpseg02 | gpseg02 | /greenplum/gpdata/primary/gpseg4
12 | 4 | m | m | s | u | 56001 | gpseg01 | gpseg01 | /greenplum/gpdata/mirror/gpseg4
7 | 5 | p | p | s | u | 55002 | gpseg02 | gpseg02 | /greenplum/gpdata/primary/gpseg5
13 | 5 | m | m | s | u | 56002 | gpseg01 | gpseg01 | /greenplum/gpdata/mirror/gpseg5
4 | 2 | p | p | s | u | 55002 | gpseg01 | gpseg01 | /greenplum/gpdata/primary/gpseg2
10 | 2 | m | m | s | u | 56002 | gpseg02 | gpseg02 | /greenplum/gpdata/mirror/gpseg2
2 | 0 | p | p | s | u | 55000 | gpseg01 | gpseg01 | /greenplum/gpdata/primary/gpseg0
8 | 0 | m | m | s | u | 56000 | gpseg02 | gpseg02 | /greenplum/gpdata/mirror/gpseg0
3 | 1 | p | p | s | u | 55001 | gpseg01 | gpseg01 | /greenplum/gpdata/primary/gpseg1
9 | 1 | m | m | s | u | 56001 | gpseg02 | gpseg02 | /greenplum/gpdata/mirror/gpseg1
Cada fila de la salida representa un nodo en Greenplum, y los campos y significados se muestran en la tabla.
2.1 Enumere los nodos que están actualmente fuera de línea
Puede monitorear el estado del nodo basado en este sql.
SELECT '当前segment host: '|| hostname||' 的role: '||role|| '状态为: '|| status FROM gp_segment_configuration
postgres-# WHERE status <> 'u';
2.2 Enumere la cantidad de nodos que se ejecutan en cada servidor del clúster
=# SELECT hostname,count(distinct dbid) FROM gp_segment_configuration
WHERE status = 'u' and role = 'p' group by hostname;
hostname | count
----------+-------
gpmaster | 1
gpseg01 | 3
gpseg02 | 3Tenga en cuenta que cuando la cantidad de nodos que se ejecutan en cada servidor de un clúster es inconsistente, todo el clúster se encuentra en un estado desequilibrado, lo que afectará el rendimiento de todo el clúster.
3. Recuperación y reequilibrio de fallos de segmento
El nodo de datos (primario o espejo) del clúster Greenplum puede fallar. Las razones del fallo incluyen, entre otras, fallas en el sistema operativo, la fuente de alimentación, la red y el disco de algunos hosts del clúster. El clúster de Greenplum configurado con MirrorSegment tiene características de alta disponibilidad. Cuando un nodo se desconecta debido a una falla, el clúster aún mantiene la integridad de los datos y puede leer y escribir. Después de solucionar problemas y reparar posibles fallas de hardware, el administrador debe usar el comando gprecoverseg para restaurar el nodo fallado al estado de funcionamiento normal lo antes posible
Cuando un nodo falla, el clúster de Greenplum puede encontrarse en las siguientes situaciones:
- Solo hay clústeres en los que el primario no tiene un espejo. Una vez que falla un primario, no se puede garantizar la integridad de los datos y el clúster de Greenplum no estará disponible.
- En un clúster configurado con Mirror, una vez que el segmento principal falla, el MirrorSegment correspondiente cambiará automáticamente al rol principal, reemplazando el nodo fallido para continuar y garantizar que el clúster esté disponible. Al mismo tiempo, se registran los cambios en la base de datos durante la falla, de modo que el nodo fallado se pueda sincronizar con el último estado durante la recuperación. Debido a que no existe un par de primario y espejo en el mismo servidor de forma predeterminada , este tipo de espejo reemplaza el estado de trabajo temporal de primario, lo que hace que el desequilibrio de la carga de trabajo entre los servidores del clúster, lo que afecta el rendimiento, por lo que debe ser reparado a tiempo.
- Cuando solo falla el segmento espejo, el segmento primario correspondiente registrará los cambios de la base de datos durante la falla. La función de cada nodo no cambiará, por lo que el impacto en el rendimiento del clúster es pequeño, pero aún debe repararse lo antes posible.
A continuación, se tomará el clúster que se muestra en la figura como ejemplo para demostrar el proceso de uso de gprecoverseg para recuperar los datos del clúster fallidos.
1) En el estado de asignación de nodo inicial, hay dos hosts de segmento en el clúster, los segmentos principales de los nodos 1 y 2 se ejecutan en el host 1 y los segmentos primarios de los nodos 3 y 4 se ejecutan en el host 2. Como se muestra en la Figura 13-1.
2) En este momento, el segmento primario n. ° 3 en el host 2 falla y el segmento espejo en el host 1 cambiará automáticamente al segmento primario para mantener disponible el clúster completo de datos. Como se muestra
3) Después de que se resuelva la posible falla del sistema de hardware en el host 2, el administrador debe ejecutar el comando gprecoverseg en el maestro. Este comando iniciará el nodo fuera de línea. Una vez que el inicio sea exitoso, la sincronización incremental entre los nodos activo y en espera comenzará para restaurar los cambios de datos durante el período fuera de línea. Durante el período de recuperación y sincronización anterior, el clúster permanece completamente disponible, pero el rendimiento se verá afectado. El tiempo empleado en el proceso de sincronización depende del tamaño de los datos que han cambiado en la base de datos durante la falla del nodo. Como se muestra
4) Una vez completada la sincronización, el sistema es como se muestra en la figura siguiente. Vale la pena señalar que, aunque el clúster siempre está disponible durante todo el proceso de falla y recuperación, el número real de segmentos primarios activados en cada host en el estado actual puede ser inconsistente. Hay 3 segmentos primarios en el host 1 y solo hay un segmento primario en el host 2. Debido a que el segmento principal realmente participa en la ejecución de los cálculos de consultas, este estado hará que la carga de trabajo en el host 1 sea 3 veces mayor que la del host 2, lo que afecta seriamente el rendimiento del clúster.
Este estado se denomina estado desequilibrado. El administrador debe ejecutar el siguiente comando en el maestro para reequilibrar los nodos y restaurar el rendimiento del clúster:
gprecovery -r, El comando de reequilibrio hará que el primario y el espejo del nodo se sincronicen fuera de línea al mismo tiempo, y la sesión del usuario permanecerá conectada, pero la consulta y la operación que se está ejecutando se cancelarán o revertirán, por lo que el administrador debe realizar la operación de reequilibrio en el momento adecuado para garantizar que se minimice el impacto en la producción. Como se muestra
Una vez que se completa el reequilibrio, el sistema volverá al estado de asignación de nodo inicial con el mejor rendimiento.
Puede utilizar el comando gprecoverseg -F para restaurar el nodo en modo de copia de texto completo.Se recomienda probar primero la sincronización incremental predeterminada.
Referencia: https://blog.csdn.net/MyySophia/article/details/102812733