Varias conferencias futuras se basarán en la primera Y. Subbotnik en bases de datos que se realizarán
en la primavera . Primero, el desarrollador Andrei Borodin habló en Y. Subbotnik. Habló sobre WAL-G, una herramienta simple y efectiva para hacer copias de seguridad de PostgreSQL en la nube, así como sobre algoritmos y tecnologías que permiten a WAL-G crear copias de seguridad más rápido. La característica principal de WAL-G son las copias de seguridad delta. En la conferencia aprenderá acerca de su implementación y cómo se está desarrollando el soporte para esta tecnología en PostgreSQL.
- hola! Soy un desarrollador de Yandex de Ekaterimburgo. A la tecnología de respaldo rápido. Hemos estado haciendo copias de seguridad durante bastante tiempo; hubo informes de
Vladimir Borodin y
Evgeny Dyukov sobre cómo investigamos y qué desarrollamos para almacenar datos de manera segura, confiable, conveniente y eficiente. Esta serie está dedicada a los últimos desarrollos en esta área.
Hablemos de las copias de seguridad en PostgreSQL en principio. La utilidad estándar para transferir datos,
pg_dump , se define como una utilidad de consola que crea un archivo con una representación lógica de sus datos.
Que es una copia lógica es bastante conveniente. Siempre puede transferir datos entre diferentes versiones, puede cortar su base de datos en pedazos, y esta es una herramienta estándar que, por ejemplo, viene en un cuadro con la utilidad de administración PgAdmin.
En primer lugar, sobre pg_dump necesita saber que esta es una herramienta para desarrolladores.
Esta no es una herramienta de mantenimiento de bases de datos. pg_dump no está diseñado para funcionar con una base de datos altamente cargada.
Suponga que todo es serio y desea utilizar la tecnología de "recuperación en un punto en el tiempo", que utiliza la API PostgreSQL para trabajar con copias de seguridad en línea. Llama a la función pg_start_backup y realiza una copia de archivo de la base de datos. De hecho, pg_start_backup obliga a la base de datos a hacer CHECKPOINT; y habilite las escrituras de página completa en el registro de escritura anticipada. La copia de la base de datos que realiza cuando llama a la API no es una copia coherente de los datos. También necesita un registro de escritura anticipada para poder restaurar su base de datos durante la llamada pg_stop_backup, es decir, al final de la copia de seguridad.
Después del tiempo de finalización de la eliminación de la copia de seguridad y en presencia de un registro líder, puede recuperarse hasta el punto deseado en el tiempo de vida de su base de datos.
La utilidad pg_basebackup se suministra en el cuadro, que implementa toda esta tecnología en forma canónica y le permite realizar copias de seguridad con la funcionalidad mínima necesaria.
Si aún eres más serio que antes, entonces usas algún tipo de software de administración de copias de seguridad, y generalmente es Barman.
El tiene varias ventajas. La ventaja principal es una utilidad muy común, tiene una gran comunidad, una gran cantidad de preguntas sobre Stack Overflow.
Solo necesita elegir un servidor de respaldo y hacer una copia de seguridad de todos sus PostgreSQL allí. Esto es muy conveniente, siempre y cuando un servidor de respaldo sea suficiente para usted.
Tan pronto como tenga muchos servidores de respaldo, debe monitorear si alguno de ellos está lleno. En caso de falla de algún servidor de respaldo, debe comprender cuáles de sus bases de datos están ahora en peligro. En principio, debe comprender dónde copiar un nuevo clúster de base de datos al crearlo.
Hay una utilidad de eliminación de copias de seguridad mucho más simple llamada WAL-E.
WAL-E ejecuta cuatro comandos principales. El comando WAL-PUSH envía un archivo WAL a la nube, y el WAL-FETCH toma un archivo WAL si debe restaurar restore_command.
También hay BACKUP-PUSH (implementa la eliminación de la API de respaldo) y BACKUP-FETCH (toma todos los datos de la nube). Los datos se almacenan en la nube, por lo que no necesita monitorear nada, esto ya es un problema del servicio en la nube, cómo garantizar la disponibilidad de sus datos cuando los necesite. Esta es probablemente la principal ventaja de WAL-E.
Hay bastante funcionalidad. Hay una lista de copias de seguridad, hay una política de retención, es decir, queremos almacenar copias de seguridad de los últimos siete días, por ejemplo, o las últimas cinco copias de seguridad, algo así. Y WAL-E puede realizar copias de seguridad en una gran variedad de servicios en la nube: S3, Azure, Google, puede llamar al sistema de archivos local la nube.
Tiene varias propiedades. En primer lugar, está escrito en Python y utiliza activamente la canalización de Unix, en parte debido a esto, tiene dependencias y no es muy productivo. Esto es normal porque WAL-E se enfoca en la facilidad de uso, la facilidad de configuración para que no pueda cometer un error al hacer un plan de respaldo. Y esa es una muy buena idea.
Hay muchas características escritas en WAL-E, y donde los autores lo desarrollaron aún más no fue muy claro para los autores. Se me ocurrió la idea de que necesito una nueva herramienta.
Su característica principal es que se reescribe en Go, casi no tiene dependencias externas, si no usa cifrado externo, y es mucho más productivo.
WAL-G fue creado originalmente por dos autores de Citus Data, y la ventaja principal se muestra en este histograma: la velocidad de envío de "ejes". Vemos que WAL-E es rápido, puede ser cualquier cosa, puede ser una gran columna cerca de cero.
WAL-G tiene un ancho de banda bastante estable. En las pruebas realizadas en Citus Data, demostró que envía de manera estable unos 800 Mb / s de "ejes".
Además, en WAL-G, por ejemplo, escribí una función que implementa una copia de seguridad de una réplica. No necesita cargar su maestro de base de datos con una carga de lectura, puede eliminar la copia de seguridad de la réplica.
Pero hay un pequeño problema. En el momento en que comience a hacer la copia de seguridad, debe nombrarla de alguna manera. El nombre incluye una línea de tiempo, que se cambiará si se promociona una réplica. Si se produce una conmutación por error en la cadena de réplicas antes de la réplica con la que está realizando una copia de seguridad, notará algunas de las réplicas, la línea de tiempo cambiará. WAL-G entiende que esta situación no es consistente, ya que al tener un nombre en la línea de tiempo anterior, el nombre le promete que puede continuar el desarrollo del historial de la base de datos en cualquier dirección existente. Pero esto no es así. Ya ha ido a una de las direcciones; no puede saltar a otra línea de tiempo con el automóvil de atrás. Por lo tanto, WAL-G comprende esta situación y no carga un archivo JSON fiscal en la nube. Creas una copia física. Pero se requiere la intervención del administrador para poder utilizar esta copia.
Hemos implementado copias delta en WAL-G, también trabajé en este desarrollo. Esto le permite tomar menos datos en la próxima copia de seguridad base, no puede hacer una copia de esas páginas de datos que no han cambiado desde la copia de seguridad anterior.
Al configurar WAL-G, especifica el número de pasos que están más lejos de la copia de seguridad base, la copia de seguridad delta, y especifica la política de copia delta. O haces una copia desde el último delta existente o haces un delta desde la copia de seguridad completa original. Esto es necesario en el caso de que el mismo componente de la base de datos siempre cambie en su base de datos, los mismos datos cambian constantemente.
¿Por qué, en principio, necesitamos copias delta de la base de datos? En teoría, tiene un WAL, por lo que puede rodar a cualquier lugar.
En un servidor ocupado, jugar el WAL de cinco segundos físicos del pasado puede tomar cuatro segundos físicos del presente. Si se le pide que retire el WAL en cuatro días, esto significa que es posible que la persona que lo solicite espere otros tres días. No siempre es una situación aceptable.
Necesita copias de seguridad básicas para todos los días, pero, sin embargo, no puede guardar allí 7 o 14 copias completas de su base de datos, aunque WAL-G las archivará, seguirá siendo bastante grande. Y en este caso, las copias delta ayudan.
Al desarrollar copias delta, se discutieron varios posibles formatos de archivos de datos. En primer lugar, se propuso el formato, cuando no desestabilizamos la página, simplemente la anulamos. Pero llegamos a la conclusión de que esta no es una forma muy efectiva, los ceros se comprimen efectivamente, pero luego rechazamos este método de almacenamiento, porque es difícil depurarlo en caso de situaciones de emergencia.
La siguiente tecnología que se consideró es primero almacenar el número de bloque y luego el bloque modificado. Pero aquí nos enfrentamos con la peculiaridad del almacenamiento en archivos TAR, que primero debemos indicar el tamaño de los archivos TAR en los que almacenamos nuestra copia delta, y luego comenzar a grabarla. Quería implementar la tecnología con un mínimo de RAM consumida, por lo que tuvimos que usar el tercer formato en el que primero leíamos completamente cada archivo de datos, buscamos las páginas de datos modificadas, primero almacenamos los números de los bloques modificados en el archivo TAR, y solo entonces los bloques modificados mismos.
Esta característica aún no se ha implementado. La estoy mirando o buscando a alguien que quiera hacer una solicitud de extracción en WAL-G. Al recuperarse de una copia delta, la base de datos sobrevive a cada una de las reencarnaciones de la base de datos en cada paso de la copia de seguridad delta. A veces, en la mitad de la vida, se eliminan algunos archivos. Al mismo tiempo, no tendríamos que preocuparnos por su condición si se eliminan de todos modos, y luego se recrean a partir de la copia delta. Esto no parece ser una característica muy complicada, por lo que si está interesado en escribir algo en Go, eche un vistazo a esta característica.
Programe sobre el uso de red, CPU y disco. En WAL-E, como vemos, el respaldo aquí aún no ha terminado, comenzó a la una de la mañana en Moscú, y no terminó en el último informe que vemos. El cronograma WAL-G ha terminado, funciona más rápido y es mucho más parejo en términos de consumo de recursos.
Lo más interesante es el gráfico del consumo de recursos durante una copia delta. Vemos que todos los recursos se han vuelto casi nulos. La carga en la CPU es casi la carga estándar en la base de datos; por la noche, se ejecutan algunas consultas. Vemos una gran punta de lectura. También me ocupo de eso, también me gustaría retirar la solicitud o lo haré yo mismo en el verano. La conclusión es que todavía tenemos que leer nuestros datos para descubrir qué ha cambiado en ellos. Esta lectura podría haberse evitado.
Hay una eliminación en WAL-G cuando indicamos el número de copias de seguridad o la fecha a partir de la cual necesitamos almacenar todas las WAL y todas las copias de seguridad base. Y WAL-G ya está lidiando con la pregunta de qué WAL y copias de seguridad base se necesitan. Hasta ahora no tenemos características que eliminen todo. En WAL-E es, también, una ocasión para una solicitud de extracción. Aún no se ha implementado un interesante comando DELETE EVERYTHING.
Hay una lista de copias de seguridad.
Establecemos la variable de entorno necesaria para que WAL-G funcione y llamamos a la utilidad de consola WAL-G. Se muestran las copias de seguridad que necesitamos ver.
WAL-G implementa muchas tecnologías para paralelizar las copias de seguridad y, en general, diversas operaciones. Por ejemplo, esta tecnología se utiliza para enviar "ejes" al archivo. Tan pronto como PostgreSQL llame a archive_command para enviar un archivo, WAL-G busca si hay más archivos listos cerca.
En general, esta no es una característica muy documentada, es muy estable en las últimas versiones de PostgreSQL, muchas tecnologías lo usan. Analizamos si hay archivos WAL listos para usar en estado de archivo, y también los enviamos junto con el que solicitó enviar la base de datos al archivo. Y cuando PostgreSQL les pide que envíen, ya los hemos enviado, estamos listos. Esto acelera significativamente el envío de WAL en bases cargadas y le permite hacer que no sea de un solo subproceso. Normalmente, PostgreSQL prepara un archivo, luego espera a que se vaya y prepara el siguiente. Logramos evitar este trabajo constante.
Durante WAL-FETCH, cuando se restaura el clúster, también intentamos descargar los siguientes archivos N que serán necesarios, y tratamos de equilibrar las pausas entre el inicio de la búsqueda previa de nuevos archivos WAL para que podamos utilizar todos los recursos que tenemos tanto como sea posible: ejecutar en la red o correr en un disco en casos raros.
Todo esto está establecido por variables de entorno.
También hay concurrencia de hacer una copia. Si bien esta característica no está presente en varias versiones, A. B. se lanzó en la versión 0.1.10 en junio de 2018, ya que el paralelismo de la lectura desde el disco le permite garantizar que se ejecute en una red o en un disco. Esto no es muy bueno con una base de datos cargada. WAL-E tenía una característica que permitía el estrangulamiento. Hasta ahora, no tenemos esto. Es necesario limitar la velocidad de eliminación de copias de seguridad para que la base pueda vivir su propia vida y servir la carga.
Nuestra característica principal no es realmente sobre tecnología.
Hace dos años, Zhenya Dyukov implementó la
tecnología delta-backup para Barman, aún no se ha llevado a cabo, la comunidad todavía lo está discutiendo.
Hace casi un año, Zhenya corrigió el error WAL-E, y lo enviamos durante seis meses (
enlace a GitHub - aprox. Ed.). Muy a menudo en las soluciones de código abierto hay un problema con el hecho de que no están muy bien mantenidas.
Con WAL-G, todo es bastante simple: lo usamos y lo mantengo. Si nosotros o usted necesitamos algo, simplemente informe que tiene un problema. Intentaremos resolverlo.
La solicitud estándar de la comunidad es simple: "hagámoslo más".
Más criptografía, más plataformas. ¿Tal vez no solo PostgreSQL, sino MySQL todavía copia de seguridad o algo más? Veo algunas otras cosas.
En primer lugar, ahora al enviar el "eje" podríamos entender qué bloques de la base de datos han cambiado, escanear estos archivos WAL y guardar información sobre lo que ha cambiado.
Y cuando cron llega con otra copia de seguridad delta, no pudimos escanear toda la base de datos, archivar ese diente de lectura de disco y simplemente saber qué páginas necesitamos arrastrar a la nube.
Intentamos usar la tecnología de seguimiento de página. Implementa el seguimiento de los cambios de página en el nivel del núcleo de la base de datos. La copia de seguridad se elimina muy rápidamente. El principal problema con PTRACK es que es muy invasivo. Contiene muchos cambios en el núcleo de PostgreSQL en lugares muy sensibles, por lo que es poco probable que se adopte pronto.
Además, sus deltas son ligeramente diferentes de los que tenemos ahora. Al eliminar el delta basado en LSN, eliminamos todos los cambios en el archivo delta que ocurrieron desde el inicio anterior hasta la hora actual.
En el caso de PTRACK, obtenemos cambios en el archivo delta, comenzando desde el delta anterior recibido. No tenemos el tiempo exacto delta antes del inicio de la copia de seguridad, antes del inicio de los cambios. Este no es el principal problema de PTRACK, en general funciona bien, pero hasta ahora es difícil de aceptar.
PTRACK no permite la eliminación delta en modo LATEST_FULL, porque almacena un mapa de bloques modificados de la eliminación anterior de este mapa. Oracle tiene una tecnología interesante, hay 8 tarjetas anteriores que guardan por si acaso. Tal vez podríamos hacer algo similar, pero hasta ahora no estamos trabajando en esta dirección.
En septiembre pasado, intenté ofrecer a la comunidad una tecnología basada en el hecho de que solo agregamos los ganchos que necesitamos al núcleo, e implementamos el seguimiento de las páginas modificadas en extensión para que el parche de seguimiento de la página no sea demasiado invasivo. Después de discutir esta tecnología, llegamos a la conclusión de que necesitamos varios prototipos, y agregaremos ganchos cuando haya prototipos. Quizás veamos cómo funcionan. Actualmente estoy trabajando en prototipos de estas extensiones que podrían usar ganchos de kernel para rastrear cambios en la base de datos.
Existe una expresión en la comunidad de que cada postgresista debe tener su propia herramienta de respaldo. Esto es malo Cada uno hace lo suyo, lo que hace una tarea de misión crítica. Debe haber una cosa en la que todo estará en la caja, todo será perfecto en un mundo ideal.
¿Qué me gustaría ver en una caja en basebackup? Nos gustaría ver, probablemente, archivar en la nube. Y copias delta.
También me gustaría compresión, concurrencia, encriptación, aceleración, listado de copias de seguridad, verificación, validación de copias de seguridad ... Muchas cosas. Entendemos que si todo esto se ofrece ahora a la comunidad, dará como resultado varias docenas de parches, que son bastante difíciles de discutir e implementar a través de commitfest. Por lo tanto, ahora todavía estamos usando una herramienta separada, pero existe el deseo de dedicar tiempo y tecnología a la comunidad para mejorar PostgreSQL.