Este artículo se comparte desde Huawei Cloud Community " GaussDB (DWS) Backup Problem Locating Ideas ", autor: yd_216390446.
prefacio
En el sistema de base de datos, las fallas se dividen en fallas internas de transacción, fallas del sistema y fallas de medios (disco). Para fallas internas de transacciones y fallas del sistema, los registros se utilizan para la recuperación automática sin intervención humana. Pero en caso de falla de los medios, debe hacer una copia de seguridad de los datos por adelantado.
Entonces, ¿cómo hacer una copia de seguridad de DWS? ¿Y qué problemas es probable que ocurran durante el proceso de copia de seguridad y cómo solucionarlos y resolverlos?
Este artículo describe principalmente el principio de copia de seguridad de la herramienta de copia de seguridad de DWS, así como las rutinas comunes de resolución de problemas y casos relacionados.
1. Principio de respaldo
copia de seguridad completa
Las copias de seguridad mencionadas en este artículo son todas copias de seguridad físicas, es decir, la base de datos se respalda copiando archivos físicos, y la base de datos se puede restaurar completamente a través de los archivos de datos, registros y otros archivos respaldados.
La copia de seguridad completa se divide aproximadamente en varias etapas: almacenamiento de línea de copia de seguridad, creación de punto de barrera, xlog de copia de seguridad, almacenamiento de columna de copia de seguridad.
- Almacenamiento de línea de respaldo: los datos del DN principal de cada nodo se comprimen y almacenan en el archivo rch
- Cree un punto de barrera: Asegúrese de que todas las transacciones en CNDN estén en un estado consistente. Es más confiable restaurar a este punto. Se escribirá un registro en XLog cuando se cree.
- Backup xlog: copia de seguridad del xlog entre startLSN y stopLSN
- Almacenamiento de columna de copia de seguridad: dado que el almacenamiento de columna no escribe xlog, se coloca al final y se ha realizado una copia de seguridad del archivo cudesc en el almacenamiento de columna en la etapa de almacenamiento de línea de copia de seguridad
El proceso general se muestra en la siguiente figura.
Problemas propensos:
- Deshabilitar el reciclaje de xlog puede causar fácilmente que el clúster sea de solo lectura
- El DDL retrasado también puede provocar que el clúster sea de solo lectura.
Puntos a tener en cuenta:
- El proceso de copia de seguridad debe abrir FPW
- Copia de seguridad XLog copia xlog entre start_lsn y end_lsn
- DDL solo se habilitará cuando se guarde la columna de respaldo
¿Por qué hay un DDL retrasado?
Operaciones DDL: alter/truncate/autovacuum/drop/vacuum full/insert overwrite Esto cambiará la declaración de relfilenode.Después de que la operación DDL obtenga la lista de almacenamiento de filas y columnas, si el usuario realiza la operación de eliminación, para garantizar la existencia del archivo, el DDL retrasado debe estar habilitado
respaldo incremental
La copia de seguridad incremental se basa en una determinada copia de seguridad y el parámetro --prior-backup-key debe agregarse al comando de copia de seguridad incremental para indicar en qué copia de seguridad se basa. Utilice el archivo cbm para identificar páginas incrementales. La copia de seguridad incremental se divide en incremental acumulativa e incremental diferencial.
- Incremento acumulativo: cada copia de seguridad se basa en la misma copia de seguridad completa, y el contenido de la copia de seguridad es la copia de seguridad completa y la modificación de datos actual
- Incremental diferencial: cada copia de seguridad se basa en la copia de seguridad anterior, y el contenido de la copia de seguridad es la modificación de datos entre las dos copias de seguridad
El principio de la copia de seguridad incremental:
- Copie solo la parte modificada de los datos la última vez y la copia de seguridad hasta el momento, la unidad mínima de copia es un bloque (8 KB)
- Cuando se realiza una copia de seguridad del clúster por primera vez, el kernel de GaussDB habilitará el parámetro guc, enable_cbm_tracking=on, y luego el kernel continuará registrando qué bloques del archivo de la base de datos se han modificado y los registrará en el directorio pg_cbm.
- Durante la copia de seguridad incremental, consulte el archivo cbm para obtener con precisión el bloque modificado y almacenarlo en la memoria, luego implemente el algoritmo de compresión lz4/zlib y escríbalo en el medio de copia de seguridad.
- Durante la recuperación incremental, obtenga el contenido de bloque de cada incremento del conjunto de copia de seguridad incremental y modifique el bloque correspondiente del archivo de base de datos según corresponda.
- Nota: Después de desactivar el parámetro guc o de eliminar el archivo cbm por error, solo puede volver a realizar una copia de seguridad completa y no puede continuar con la copia de seguridad incremental.
¿Qué es un archivo cbm?
Se modificó el mapa de bloques, que proporciona información de modificación de la página de datos externos y una interfaz externa. De acuerdo con la información de cbm, la información de modificación incremental de los archivos de datos (almacenamiento de filas y almacenamiento de columnas) entre dos copias de seguridad se puede obtener y respaldar directamente
El impacto de la copia de seguridad en el sistema:
- La copia de seguridad ocupa el sistema IO, negocio lento
- DDL retrasado, lo que resulta en una acumulación de xlog, aumentando el espacio en disco
- La copia de seguridad incremental puede causar fácilmente una acumulación de archivos cbm, lo que da como resultado clústeres de solo lectura
2. Problema de rutina de posicionamiento
1) Proceso de llamada de respaldo
Plano de control DWS/plano de control FI -> GaussRoach.py/SyncDataToStby.py -> gs_roach kernel
El plano de control invoca el script python de roach, que analiza los parámetros e invoca el comando gs_roach en el lado del kernel.
2) Si la copia de seguridad falla, debe verificar la ruta del registro:
- Clúster HC/HCS/HCSO
- Registro de llamadas del plano de control: fuera de la zona de pruebas /home/Ruby/log/cloud-dws-deploy.log
- Registro de archivo del plano de control: fuera de la zona de pruebas /home/Ruby/archivelog
- Registro del kernel: /var/chroot/DWS/manager/backup/log en la zona de pruebas
- clúster fuera de línea
- Registro del núcleo: $GAUSSLOG/roach/agent
- Registro lateral de Python: $GAUSSLOG/roach/controller
- registro de observación:
- cd $GAUSSLOG/bin/gs_obs en la caja de arena
- Vi gs_obs.run.log para ver el número de error correspondiente Tenga en cuenta aquí que el registro obs debe verse en el nodo de error específico
3) Comandos grep de uso común:
Ver la ip del nodo maestro: grep “IP maestra” roach_agent*.log
Ver el progreso de la copia de seguridad: grep "Configuración del estado del agente en" roach_agent*.log
Ver el tiempo de respaldo: grep "Tiempo tomado" roach_agent*.log | grep "MAESTRO"
Verifique si la copia de seguridad fue exitosa: grep "Operación de copia de seguridad EXITOSA. Clave de copia de seguridad" roach_agent*.log
查看roach_client ip：grep “Éxito en los medios remotos conectados” roach_agent*.log
Ver asignación de subprocesos: grep “allotInstanceForMyProc” roach_agent*.log
Ver los parámetros del comando de copia de seguridad: grep “command_dict” roach_controller*.log
Si el archivo está empaquetado, use el "comando zgrep para verlo"
4) Registros de claves de copia de seguridad
| palabras clave |
ilustrar |
|---|---|
| Creando el agente Thread Roach |
Comience a crear el proceso del agente |
| RAGENT_EXEC_PREPARING_METADATA es |
Comience a preparar la lista de metadatos |
| ingrese la devolución de llamada de la copia del almacén de filas |
comenzar respaldo |
| realizar copia de seguridad entrar |
En realidad, comience a ejecutar la transferencia de disco a rch |
| empezar a retrasar el reciclaje de ddl antes de la copia del archivo col |
Habilitar DDL retrasado |
| Establecer el estado del agente en [AGENT_CREATING_BARRIER] |
Empieza a crear barreras |
| RAGENT_EXEC_BACKUP_XLOGFILES vienen |
El agente comienza a hacer una copia de seguridad del xlog. |
| ingrese la devolución de llamada de la copia de colstore |
comenzar respaldo |
| detener el retraso del reciclaje de ddl después de haber copiado todos los archivos col |
Desactivar DDL retrasado |
| Estableciendo el estado Maestro en [PERFORM_BOOKKEEPING_INFO] |
Una vez finalizada la copia de seguridad, el nodo maestro comienza a resumir los resultados |
3. Casos relacionados
(1) Error de copia de seguridad de grano fino No se pudo conectar a gauss (xxx) a través de libqp
[Descripción del problema] El agente informó un error No se pudo conectar a gauss (host: local, puerto: 25308) a través de libpq, ERROR: el puntero de conexión es NULL durante la copia de seguridad
【Plan de solución de problemas】
- Debido a que "host:25308" se informa como una conexión de error, verifique el registro cn del nodo de tiempo correspondiente
- cn informó un error FATAL: "base/2278052" no es un directorio de datos válido, se sospecha que es un problema con la base de datos
- Conéctese manualmente a la base de datos y descubra que no se puede conectar
- El directorio no existe en el directorio de la instancia dn, lo que se debe a residuos
- drop database elimina la base de datos y realiza una copia de seguridad con éxito
[Causa del problema] Hay archivos residuales en la base de datos
[Solución alternativa] Elimine los archivos residuales de la base de datos
(2) La copia de seguridad falla aleatoriamente
[Descripción del problema] Los problemas de NBU provocan errores de copia de seguridad aleatorios
【Plan de solución de problemas】
- Verifique el registro del controlador, muestra que el primer nodo de error es xx.xx.xx.148
- Vaya al nodo anterior para verificar el registro del agente, informe un error "Mensaje incompleto del cliente de Roach" y descubra que el registro apunta al servidor de medios, así que verifique el registro del cliente de Roach
- Sospeche que es un problema con nbu, verifique el registro correspondiente en el nodo roach_client correspondiente, encuentre la dirección IP de roach_client a través de grep "Success to connected Remote Media" roach_agent*.log, ssh al nodo roach_client correspondiente y el error correspondiente el informe es un informe de error en NBU, "llame a NbuManager::CreateFile error", coopere con colegas del lado de NBU para verificar
[Causa del problema] En general, la situación anterior se debe a demasiada simultaneidad en el lado de la cucaracha, lo que genera una gran carga en la NBU y un error en la copia de seguridad, pero los detalles específicos deben coordinarse con la NBU para verificar en el Mismo tiempo
[Precauciones] Si se trata de un problema de concurrencia, se recomienda aumentar el parámetro de tamaño de división de archivos y reducir el parámetro de proceso paralelo, y reiniciar la copia de seguridad
¿Bajo qué circunstancias debo cooperar con los colegas de NBU para investigar?
Por lo general, cuando aparecen palabras clave como xbsa o crear archivo en el registro roach_client
(3) La conexión entre el maestro y el agente falla, lo que resulta en una falla de respaldo
[Descripción del problema] La conexión entre el maestro y el agente falla, lo que provoca una falla en la copia de seguridad.
【Versión relacionada】
[Solución de solución de problemas] El registro informa que la conexión entre el maestro y el agente falló y que los agentes no se conectaron en 600 segundos.
【causas del problema】
En el entorno HCS, solo se abren los puertos 55000 y 56000, y el puerto no está abierto, lo que genera un error
【Evitación de problemas】
Solución 1: modificar el puerto de comando de cucaracha
Solución 2: Abra el puerto correspondiente
(4) La copia de seguridad detallada no puede encontrar la información del archivo e informa un error
[Descripción del problema] Se informa un error para la copia de seguridad detallada Error: error al obtener la información del archivo.
【Versión relacionada】
[Solución de solución de problemas] Verifique el registro del agente del nodo de informe de errores, y la bifurcación principal de copia de seguridad de la relación xxx falló, Error: Error al obtener la información del archivo.
[Causa del problema] Las operaciones DDL no se admiten durante la copia de seguridad detallada. Antes de la copia de seguridad detallada, se generarán los archivos MAP de todas las tablas para registrar los nombres de las tablas involucradas y las tablas relacionadas de las tablas.Todas las declaraciones que involucren la modificación de la operación DDL del relfilenode harán que la copia de seguridad falle, como alterar/truncar/autovacuum/drop/vacío completo/insertar sobrescribir, etc.
【Evitación de problemas】
Escenario 1: tiempo comercial relacionado con copia de seguridad y DDL escalonado
Solución 2: reduzca adecuadamente las tablas involucradas en cada copia de seguridad, lo que puede reducir la tasa de fallas de la copia de seguridad causada por DDL
(5) El proceso de copia de seguridad informa un error de que la memoria no está disponible temporalmente
[Descripción del problema] La memoria de error no está disponible temporalmente en la etapa de copia de seguridad de metadatos de volcado.
【Plan de solución de problemas】
La memoria del controlador no está disponible temporalmente.
[Razón del problema] El parámetro cpu-cores es demasiado grande, lo que genera una memoria lenta
[Evitar problemas] Reducir el parámetro cpu-cores
(6) La lectura frecuente de cms por cucaracha en un grupo grande conduce a un estado de grupo inestable
[Descripción del problema] Cuando se inicia la copia de seguridad, el panel de administración y control muestra que el estado del clúster es anormal. Cuando gs_roach se inicia en un clúster grande, accederá con frecuencia a cms para leer el estado del clúster, lo que hará que cm_ctl consulte el estado del clúster. inestable.
[Versiones relacionadas] Versiones anteriores a la 821 (excluyendo la versión 821)
【Plan de solución de problemas】
- Consulte el registro de cm_server (el punto en el tiempo después de que se inicia la cucaracha) e informe un error "CmPqPutMessage return error ret=xx"
- $GAUSSLOG/bin/cm_ctl log, error "error al enviar mensaje de consulta a cm_server"
【causas del problema】
Durante el inicio de roach, el comando cm_ctl se llama con frecuencia, y la cantidad de nodos del clúster es grande y la cantidad de simultaneidad es alta, lo que hará que la secuencia de comandos de monitoreo del estado del clúster de la página no pueda ejecutar cm_ctl
【Evitación de problemas】
Actualizar a la versión 821
4. Resumen de problemas comunes
Documentos relacionados:
Implementación de copia de seguridad y recuperación del almacén de datos en la nube de Huawei GaussDB (DWS): https://bbs.huaweicloud.com/blogs/185928
Resumen de la copia de seguridad completa del almacén de datos GaussDB (DWS): https://bbs.huaweicloud.com/blogs/242694
Haga clic para seguir y conocer las nuevas tecnologías de Huawei Cloud por primera vez~
El sistema operativo Maya desarrollado por el Ministerio de Defensa de la India, que reemplaza por completo a Windows Redis 7.2.0, y el sitio web oficial de la versión 7-Zip de mayor alcance fue identificado como un sitio web malicioso por Baidu Go 2 nunca traerá cambios destructivos a Go 1 Xiaomi lanzó CyberDog 2, más del 80% de la tasa de código abierto ChatGPT costo diario de alrededor de 700,000 dólares estadounidenses, OpenAI puede estar al borde de la bancarrota Se incluirá el software de meditación, fundado por la "primera persona de Linux en China" Apache Doris versión 2.0.0 Lanzamiento oficial: rendimiento de prueba ciega 10 veces mejorado, experiencia de análisis extremadamente rápida más unificada y diversa La primera versión del kernel de Linux (v0.01) interpretación de código fuente abierto Chrome 116 se lanza oficialmente