“Es paradójico, pero cierto, decir que cuanto más sabemos, más ignorantes nos volvemos en el sentido absoluto, porque solo a través de la iluminación nos hacemos conscientes de nuestras limitaciones. Precisamente uno de los resultados más gratificantes de la evolución intelectual es la continua apertura de nuevas y mayores perspectivas.” Nikola Tesla
PostgreSQL es un proyecto impresionante y evoluciona a un ritmo asombroso. Nos centraremos en la evolución de las capacidades de tolerancia a fallas en PostgreSQL a lo largo de sus versiones con una serie de publicaciones de blog.
PostgreSQL en pocas palabras
PostgreSQL es tolerante a fallas por su naturaleza. Primero, es un sistema avanzado de administración de bases de datos de código abierto y este año celebrará su vigésimo cumpleaños. Por lo tanto, es una tecnología probada y tiene una comunidad activa, gracias a lo cual tiene un progreso de desarrollo rápido.
PostgreSQL es compatible con SQL (SQL:2011) y totalmente compatible con ACID (atomicidad, consistencia, aislamiento, durabilidad).
PostgreSQL permite la replicación física y lógica y tiene soluciones de replicación física y lógica integradas. Hablaremos sobre los métodos de replicación (en las próximas publicaciones del blog) en PostgreSQL con respecto a la tolerancia a fallas.
PostgreSQL permite transacciones sincrónicas y asincrónicas, PITR (recuperación en un momento dado) y MVCC (control de concurrencia multiversión). Todos estos conceptos están relacionados con la tolerancia a fallas en algún nivel e intentaré explicar sus efectos mientras explico los términos necesarios y sus aplicaciones en PostgreSQL.
¡PostgreSQL es robusto!
Todas las acciones en la base de datos se realizan dentro de transacciones , protegido por un registro de transacciones que realizará una recuperación automática de fallas en caso de falla del software.
Las bases de datos se pueden crear opcionalmente con sumas de comprobación de bloques de datos para ayudar a diagnosticar fallas de hardware. Existen varios mecanismos de copia de seguridad, con PITR completo y detallado, en caso de que sea necesaria una recuperación detallada. Hay disponible una variedad de herramientas de diagnóstico.
La replicación de la base de datos se admite de forma nativa. Replicación síncrona puede proporcionar más de “5 nueves” (99,999 por ciento) disponibilidad y protección de datos, si se configura y gestiona correctamente.
¡Teniendo en cuenta los hechos anteriores, podemos afirmar fácilmente que PostgreSQL es robusto!
Tolerancia a fallas de PostgreSQL:WAL
El registro de escritura anticipada es el principal sistema de tolerancia a errores de PostgreSQL.
El WAL consiste en una serie de archivos binarios escritos en el subdirectorio pg_xlog del directorio de datos de PostgreSQL. Cada cambio realizado en la base de datos se registra primero en WAL, de ahí el nombre de registro de "escritura anticipada", como sinónimo de "registro de transacciones". Cuando se confirma una transacción, el comportamiento predeterminado y seguro es forzar los registros WAL en el disco.
Si PostgreSQL falla, se reproducirá el WAL, lo que devuelve la base de datos al punto de la última transacción confirmada y, por lo tanto, garantiza la durabilidad de cualquier cambio en la base de datos.
¿Transacción? ¿Comprometer?
Los cambios de la base de datos en sí mismos no se escriben en el disco en la confirmación de la transacción. Esos cambios se escriben en el disco en algún momento posterior por el escritor de fondo o el punto de control en un servidor bien ajustado. (Consulte la descripción de WAL anterior. )
Las transacciones son un concepto fundamental de todos los sistemas de bases de datos. El punto esencial de una transacción es que agrupa múltiples pasos en una sola operación de todo o nada.
Los estados intermedios entre los pasos no son visibles para otras transacciones simultáneas y, si se produce algún error que impide que se complete la transacción, ninguno de los pasos afectará en absoluto a la base de datos. PostgreSQL no admite lecturas sucias (la transacción lee los datos escritos por una transacción concurrente no confirmada ).
Punto de control
La recuperación de fallas reproduce el WAL, pero ¿desde qué punto comienza a recuperarse?
La recuperación comienza desde puntos en el WAL conocidos como puntos de control . La duración de la recuperación de fallas depende de la cantidad de cambios en el registro de transacciones desde el último punto de control. Un punto de control es un punto de inicio seguro conocido para la recuperación, ya que garantiza que todos los cambios anteriores a la base de datos ya se hayan escrito en el disco.
Un punto de control puede ser inmediato o programado . Los puntos de control inmediatos son activados por alguna acción de un superusuario, como el CHECKPOINT comando u otro; PostgreSQL decide automáticamente los puntos de control programados.
Conclusión
En esta publicación de blog, enumeramos características importantes de PostgreSQL que están relacionadas con la tolerancia a fallas en PostgreSQL. Mencionamos el registro de escritura anticipada, la transacción, el compromiso, los niveles de aislamiento, los puntos de control y la recuperación de fallas. Continuaremos con la replicación de PostgreSQL en la próxima entrada del blog.
Referencias:
Documentación de PostgreSQL
Recetario de administración de PostgreSQL 9:segunda edición
