Le sugiero que lea el descifrado del informe por Andrey Salnikov de Data Egret "Herramientas de creación de copias de seguridad PostgreSQL" . Al final, una tabla resumida actualizada de herramientas
Esta charla trata sobre las herramientas de copia de seguridad PostgreSQL disponibles. Copias de seguridad lógicas, copias de seguridad binarias, herramientas de copia de seguridad integradas y herramientas de terceros. ¿Se necesitan copias de seguridad incrementales cuando realmente pueden ayudar? Veamos cuándo y qué herramienta es más apropiada para usar. ¿Cuál es la mejor manera de automatizar el proceso de respaldo y verificar la integridad de un respaldo? Eche un vistazo más de cerca a herramientas como pg_dump , pg_basebackup , barman , wal-e , wal-g , pgbackrest , BART y pg_probackup .
Mi nombre es Andrey Salnikov, soy un empleado de Data Egret y este informe estará dedicado a las herramientas para crear copias de seguridad en PostgreSQL.
Primero acerca de quiénes somos, mi compañía. Nuestra actividad principal: trabajamos como administradores remotos y tenemos un número bastante grande de clientes. Hay bases enormes, hay un montón de bases pequeñas, hay todo tipo de mezclas cuando una base grande o un montón de bases pequeñas. También proporcionamos servicios de consultoría y auditoría: este es el caso si las personas no necesitan un apoyo constante, pero se necesita algún tipo de experiencia.
Dado que PostgreSQL es un producto de código abierto, naturalmente participaremos en todo tipo de conferencias en términos de compartir nuestra experiencia y ayudar a PostgreSQL a hacer lo mejor. Porque la base de datos PostgreSQL es realmente buena. Y resulta que vimos muchos perfiles de carga: cargas DWH y cargas WEB, y mezclas de carga. Y las bases estaban cayendo de diferentes maneras. Mucha experiencia
Esta es la parte más interesante del informe. ¿Por qué se necesitan copias de seguridad? De hecho, son necesarios para que podamos descansar en paz, para que podamos dormir en paz, para poder pasar el rato en los conciertos con calma. Ahora, este es el objetivo principal desde el punto de vista de la base por la que se necesitan copias de seguridad. Para que todo esté tranquilo en nuestras vidas. Porque si hay copias de seguridad verificadas, entonces podemos hacer todo esto. Pero lo que está sucediendo con la base es la décima cosa.
¿Cuál es el rango de herramientas para crear copias de seguridad en el mundo de PostgreSQL? Esta es la herramienta de recuperación integrada pg_dump, pg_dumpall o pg_restore. Esta es la única herramienta que le permite hacer copias de seguridad lógicas. Es decir, puede pg_dump, tanto en SQL para volcar, como en un pequeño formato binario para volcar datos. Y sale de la caja con PostgreSQL.
La siguiente herramienta (pg_basebackup) para crear copias de seguridad, que también sale de la caja y comienza con esta herramienta, y todas serán herramientas para crear copias de seguridad de bases de datos binarias. Pg_basebackup también es una herramienta que viene de fábrica, que nos permite cargar repositorios postgreSQL y tomar una copia binaria de la base de datos, disparar una base de datos persistente y, si queremos poder archivar a tiempo, podemos configurar PostgreSQL para volcarlo a algún tipo de disco. Estas son las herramientas básicas. Son buenos, lo hacen, realizan su funcionalidad a las 5, pero son inconvenientes en términos de gestión y algún tipo de masa. Cuando tenga 20 bases de datos, deberá hacerlo usted mismo mediante secuencias de comandos.
Las siguientes dos herramientas son herramientas específicas de la nube pura: wal-e y wal-g. Los mismos chicos los están desarrollando, pero el desarrollo de wal-e terminó y cambiaron a wal-g. Estas herramientas están orientadas principalmente para AWS y para el almacenamiento en S3. Wal-e todavía puede trabajar con Google Cloud, con Azure y con el sistema de disco, solo puede especificar algún tipo de unidad remota. Wal-g solo funciona con AWS, solo con S3. Bueno, o cualquier otra interfaz similar con S3. Los usamos, cosas buenas. Desarmaré aún más cada herramienta en detalle.
Y en el próximo paquete de herramientas, estas son herramientas que dependen de pg_basebackup o que lo usan directamente, o que de alguna manera implementan su funcionalidad. Todos están escritos por desarrolladores que se comprometen con el principal PostgreSQL y tienen su propio comercial de fork, que promueven en su círculo de influencia.
La herramienta de barman más popular, que utilizamos ampliamente en el país. Esto es esencialmente un contenedor de Python alrededor de pg_basebackup. También puede funcionar en protocolos ssh. Una herramienta pgbackrest muy interesante y muy prometedora. PostgreSQL participa en el desarrollo y se compromete activamente con él. Originalmente fue escrito en Python. Ahora, la versión que se utiliza: está escrita en C para acelerar y la posibilidad de eliminar paralelamente las copias de seguridad.
Pg_probackup es una utilidad de nuestros colegas rusos en PostgreSQL Professional que le permite realizar copias de seguridad incrementales, que son bastante pequeñas.
Y la última utilidad es la herramienta de copia de seguridad y recuperación (BART) de EnterpriseDB. Ella no es muy popular con nosotros. Es principalmente para CentOS y Red Hat. Para Ubuntu, con ella, en mi opinión, difícil. Y debido a la baja popularidad de BART entre nosotros, casi no se encuentra en ninguna parte de las instalaciones.
Intentaría dividir estas herramientas en algunas cosas que son importantes.
Primero, es importante para nosotros cómo lo almacenaremos, en qué unidades y en qué servicios. Y hay una lista de características que veremos.
La siguiente separación de datos, aquí subdivido que, al eliminar la copia de seguridad o restaurar la copia de seguridad, podemos cortar parte de todo el servidor de base de datos (servidor) y trabajar con ella como una base de datos integral e integral.
Cuánto admiten diferentes versiones de la base de datos.
¿Qué modos de funcionamiento tienen en términos de paralelismo, en términos de algún tipo de automatización y similares?
Y la facilidad de servicio es cuánto podemos separarlos en un servicio separado, que a su vez pasará por las bases de datos y eliminará las copias de seguridad de acuerdo con algún cronograma.
Validación: quería que se verificara la copia de seguridad para garantizar que luego podamos recuperarnos de ella y que tengamos una base normal e ininterrumpida.
Y ahora, veamos estos seis grandes puntos con más detalle. Y marcaré allí qué instrumento nos dará.
Por almacenamiento, pueden almacenar todo en el sistema de archivos, es decir, podemos volver a montar nuestro disco en el sistema operativo y copiar copias de seguridad allí. Todas las herramientas te permiten hacer esto. Una unidad de red montada es básicamente la misma, ya que se obtiene en nuestro sistema de archivos local.
En AWS (S3), tres herramientas pueden funcionar para nosotros: wal-g, wal-e, pgbackrest. Porque entre tales utilidades: barman, etc., es la única que puede funcionar con AWS (S3).
Con Azure, solo wal-e. Google Cloud es solo wal-e.
- Pg_dump, pg_dumpall nos proporciona una copia lógica de los datos. La diferencia entre ellos es que pg_dumpall procesa toda la instancia de la base de datos (servidor), en pg_dump puede especificar una base de datos específica en la instancia y trabajar con ella.
- Las copias binarias son todo lo demás.
- Un factor importante durante el almacenamiento es que si estamos limitados de alguna manera por los recursos del disco, a menudo surgen situaciones cuando dividimos la base de datos en diferentes espacios de tabla. Esto también es cierto para los servidores de hierro, ya que no desea sufrir RAID. Esto es cierto para las nubes, porque debido a que hay una cierta limitación, especialmente cuando toma un automóvil con discos NVME y cuántos están conectados, muchos están conectados. Las instancias de AWS se expanden, pero con unidades EBS. Y al restaurar los datos, será importante para nosotros que podamos redistribuir estos espacios de tablas, asignarlos a lo largo de nuevas rutas y a nuevos discos. Y ahora esta buena propiedad está presente en wal-e. En wal-g todavía no saben cómo trabajar con él. Pg_probackup puede funcionar con él. Barman, basebackup, pgbackrest. Esto suele ser importante, especialmente cuando tiene una base de datos de 8-10 TB. Entre nuestros clientes de producción, casi todas estas bases de datos están colapsadas en espacios de tablas.
Ahora sobre qué tamaño podemos tener copia de seguridad. Todo esto irá en el contexto de las copias de seguridad binarias. Está claro que la copia de seguridad binaria es cuánto pesa la base de datos con nosotros, tanto copiamos. Pesa 8 TB, copiamos 8 TB. 1 MB pesa 1 MB, copiado. ¿Cómo ahorrar espacio cuando queremos una larga cadena de copias de seguridad? Para hacer esto, se me ocurrieron algunas herramientas. Es decir, la base de datos almacena datos en sus archivos. Si tenemos una base de datos de archivo larga, generalmente cambiamos allí un pequeño porcentaje de estos archivos. Y para esto, se les ocurrió una copia de seguridad diferencial.
Copia de seguridad diferencial, ¿qué es? Observamos qué archivos han cambiado y solo copiamos al almacenamiento, dónde almacenar la copia de seguridad. Y vincularemos todos los demás archivos con un enlace duro a esta base de datos. Resulta que así ahorramos espacio. Y al mismo tiempo, podemos eliminar de forma segura las copias de seguridad de bases de datos antiguas sin estropear las más recientes.
Esto es bueno, pero decidimos seguir adelante y se nos ocurrió una copia de seguridad incremental. Las copias de seguridad incrementales son de dos tipos.
El primero es a nivel de archivo. Difiere de la copia de seguridad diferencial solo en que la copia de seguridad diferencial se centra en una copia de seguridad completa de su base de datos y, en relación con una copia de seguridad completa, copia archivos y copias de diferencias. La copia de seguridad incremental puede centrarse en copias de seguridad diferenciales, copia solo aquellos archivos modificados que han cambiado en comparación con la copia de seguridad diferencial. Para incremental, necesitará toda la cadena de copias de seguridad. Es decir, la copia de seguridad principal -> 1ª copia de seguridad incremental (siempre será diferencial) -> luego todas las copias de seguridad incrementales. La copia de seguridad diferencial siempre se centra en una base de datos de copia de seguridad completa. Incremental puede enfocarse en otros tipos de respaldo.
Pg_probackup y BART fueron la forma de crear copias de seguridad incrementales por bloque. Porque no podemos cambiar todo el archivo, sino el bloque de datos. Y estas utilidades se ejecutan a través de archivos wal y seleccionan exactamente los bloques que han cambiado. Estos bloques de copia de seguridad se copian en la copia de seguridad. Para recuperarse con una copia de seguridad incremental de este tipo, también necesitará una copia completa de la base de datos y además deberá guardar estas piezas incrementales que se escriben desde wal. Esto impone algunas limitaciones de la utilidad, ya que deben ejecutarse a través de archivos wal. PostgreSQL Professional también tiene una capa sobre la estructura de archivos de la base de datos. Por lo tanto, están buscando rápidamente estos bloques. Tales copias de seguridad incrementales son muy pequeñas. Si tiene un pequeño% de cambio en la base de datos y debido al hecho de que se escribe una gran cantidad de información técnica en el archivo wal, estas utilidades respaldan decenas de kilobytes de datos por 1 wal.
Mayor intercambio de datos. Esto implica que si necesitamos hacer una copia de seguridad, no todo. O restaurar no todo. Esto solo es posible con copias de seguridad lógicas, y esto nos permite hacer solo pg_dump. Las utilidades proporcionan una funcionalidad bastante amplia. Pg_dump puede permitirle volcar la estructura de la base de datos si es necesario. Puede volcar específicamente una tabla o puede excluir una tabla del volcado o volcar la lista de tablas, excluir la lista. La funcionalidad es bastante amplia a este respecto. La desventaja de esto es que cuando se recupera de un volcado de este tipo, si tiene una base de datos grande, tendrá que pasar mucho tiempo para recuperarse de ella, porque todo esto debe reproducirse en una instancia pura de PostgreSQL.
Estas utilidades son muy convenientes para usar el caso cuando sobreestimamos nuestras fortalezas y no creamos un montón de pequeñas bases de datos. Podemos fusionarlos en una instancia. Podemos verlo de esta manera si nuevamente evaluamos nuestra fortaleza, nuestra base de datos está hinchada o si estamos cambiando la arquitectura de un monolito a uno de servicio y aserrando los datos. Pg_dump en este caso es lo único que le permite hacer esto sin dolor.
También puede restaurar una base de datos y pgbackrest se enumera aquí. Él tiene tal chip, que podemos indicar que solo necesitamos una base de datos de respaldo binario. Que esta haciendo el Restaura la base de datos predeterminada de la copia de seguridad, esto es plantilla y postgres y la base de datos que especificamos. Todas las demás bases de datos, restablece los archivos y los hace de longitud cero. Es decir, PostgreSQL tiene una estructura transparente para almacenar bases de datos en archivos, allí puede, por así decirlo, reducir la base de datos restaurada. Supongamos que necesitamos encontrar qué datos urgentes de un binario, no queremos aumentar la base de 10 TB, tenemos dos bases allí y aumentamos una, lo que permite un total de 5 TB. En este caso, por supuesto, se viola la consistencia, pero para algunas soluciones rápidas, cuando necesita extraer urgentemente sangre de la nariz de una gran base de datos, de la cual hay varias, estas son características muy buenas. Pero como una base de datos de respaldo completa no debe considerarse durante la recuperación. Es decir, es para trabajos de emergencia.
¿Cómo es el trabajo con muchas versiones de la base de datos? Aquí, también, todo es bastante interesante. Pg_dump es muy bueno porque no estamos vinculados a qué versión de la base de datos para restaurar. Hay un modo de texto sin formato, y es solo SQL puro, que describe la estructura completa de la base de datos, todos los datos. En principio, puede recuperarse de donde quiera, en MySQL, en MSSQL, en Oracle con algunas ediciones en este volcado. Entre las versiones principales de PostgreSQL, estos volcados también son bastante fáciles de usar.
Versiones múltiples, ¿qué quiero decir con esto? Esto es hasta qué punto la utilidad puede procesar diferentes versiones de bases de datos y trabajar simultáneamente con PostgreSQL 9.6, 10, 11. Todo, excepto los integrados de pg_dump y pg_basebackup, porque están vinculados a la versión específica con la que vienen. El resto se centra en estas utilidades. Se pueden indicar donde se encuentran pg_basebackup, pg_dump de diferentes versiones. Ellos, respectivamente, con la versión de PostgreSQL, eligen la última utilidad para eliminar la copia de seguridad.
Todas las utilidades, excepto pg_dump, son adecuadas para crear réplicas y servidores en espera, ya que son copias de seguridad lógicas. Con cualquiera de estas utilidades, puede restaurar los servidores y conectarse al asistente para que funcione como una réplica de este servidor.
Cómo se pueden eliminar las copias de seguridad en general, qué modos existen para eliminar las copias de seguridad. Simplemente puede copiar archivos utilizando herramientas estándar del sistema operativo: a través del protocolo ssh (rsync, scp) y posiblemente algunas otras utilidades que son. Por qué existe esa oportunidad, porque le permiten paralelizar la copia. Pgbackrest solo funciona de esta manera, barman puede funcionar de esa manera, y puede funcionar usando el protocolo PostgreSQL.
Protocolo PostgreSQL: cuando la utilidad de copia de seguridad se conecta a PostgreSQL y extrae todos los archivos y los registros de archivo que surgen durante el proceso de copia de seguridad utilizando el protocolo de replicación. Todos los demás y el barman pueden hacerlo.
Básicamente, todo puede hacer una copia de seguridad desde una réplica, depende de la versión de PostgreSQL. Con PostgreSQL 10 y 11, podemos eliminar las copias de seguridad de una réplica. Pero no recomiendo esto, en general, nadie de nuestra compañía lo recomendará. Debido a que hay situaciones en las que se perdió el monitoreo, tomaron una copia de seguridad de la réplica durante un mes, que se cayó del servidor maestro y no es relevante. Es decir, las copias de seguridad en cualquier caso siempre deben eliminarse del servidor maestro. Solo en este caso, estará seguro de tener una base de datos de respaldo realmente actualizada.
Copias de seguridad de subprocesos múltiples: todos pueden hacer esto, porque todo es por diferentes razones, alguien a través del protocolo ssh, alguien implementado en el nivel de copia de la base de datos. Excepto pg_basebackup y BART, porque la operación BART solo está en pg_basebackup cuando se elimina la copia de seguridad y, desafortunadamente, es de un solo subproceso y no tendrá subprocesos múltiples.
Un ejemplo de multihilo. Estaba restaurando una base de datos de 8 TB. Cuando se concentra en elegir un sistema para eliminar las copias de seguridad, sepa que wal-e está escrito en Python, wal-g está escrito en Golang. Tuve que restaurar la base de 8 TB. Wal-e se topó con la limitación de Python y me arrastró con AWS a una velocidad de 600 Mbps. Cuando cambié a wal-g, tenía una situación en la que no podía trabajar con copias de seguridad de wal-e, pero podía extraer archivos wal. Por lo tanto, esta imagen del medio aquí es la restauración de la base de datos. Luego rodó wal, que yacía allí en S3 y fue restaurado a un cierto punto en el tiempo. Wal-e se topó con la limitación de Python y la concurrencia en Python, es muy condicional. Un wal-g se topó con la interfaz S3, es decir, qué tan rápido podría dar S3 en cada momento, tan rápido que tomó. En promedio, fue de 2 Gb / s, que es lo suficientemente bueno. Es decir, con wal-e, se recibió una hora de cambios en la base de datos en 45 minutos de copia de seguridad continua. Con wal-g, resultó que rodaron una hora en algún lugar de la base de datos durante aproximadamente 5 minutos.
Modos de funcionamiento, lo que es interesante aquí en el sistema de respaldo.
- Recuperación en el tiempo a un punto específico. Si hemos archivado registros y los copiamos, podemos restaurarlos. Le permite hacer un sistema de respaldo, es como un factor estándar. Lo principal es que almacenamos archivos wal en algún lugar. Los vertederos, por supuesto, no saben cómo, porque son un poco acerca de otra cosa.
- Ajustar la carga en la red es algo muy importante, porque como dije, es deseable eliminar el volcado del servidor maestro, luego se garantiza que realmente obtendrá la copia de seguridad real. Bueno, a veces sucede que los servidores están tan cargados que es bastante difícil entrar allí. Tenemos algunos clientes pegan una interfaz de red separada. A veces se realiza un tiempo de carga mínimo. También es bueno cuando podemos especificar la carga en la red al crear una copia de seguridad. Esto le permite hacer pg_basebackup, barman y BART, wal-e, wal-g.
- Compresión sobre la marcha. Esta es una cuestión de cuánto transmitiremos a través de la red. Si podemos comprimir el archivo antes de enviarlo al repositorio, entonces esto es bueno sobre la marcha. Y casi todos pueden hacerlo, aquí. Lo principal es indicar el nivel de compresión allí.
Capacidad de servicio, ¿qué es lo interesante aquí para los sistemas de respaldo?
- CLI — , , , , . , CLI, , , . , , .
- barman, pgbackrest BART, . , 20-30 , , , , backup- . , , .
- – , , backup-, , backup-. , - . . .
- – backup-, , - . , , . , , , , wal , , . wal-e, wal-g, , backup - . 7 backup .
backup. , backup, backup , , . , . , . . stage . , , backup . CLI , backup .
, , . , backup . , . , . , . . checksum PostgreSQL. , checksum PostgreSQL. checksum, .
pgbackrest pg_probackup backup , checksum. checksum.
, backup, checksum , , checksum . .
:
. , . , .
: , backup , , , . , , backup. , , - , , , , , , . - ?
: , , . . . - , , backup , , , . , . , , , , , , / . , , . , . , . , .
: , , ? .
: . 4 . . . backup. . , .
: ?
: . . wal-e, wal-g, pgbackrest. borman, pg_dump, basebackup. , , . .
: , - PostgreSQL, , , postgis - -?
: , backup , . checksum , PostgreSQL checksum, , . postgis, - . Pg_dump , , , SQL . SQL . . , , . dump, .
: , . , - ?
: . dump , . , – , , - , , . , . , - , .
: , , , bloat ?
: .
: — , - . , Symantec, Veritas Backup Exec . PostgreSQL?
: , , . PostgreSQL , pg_start_backup. , . .
: , - Symantec, Veritas Backup Exec .
: .
: , , . checksum - , , - ?
: — . stage , . stage . . . , -, . . .
: , WAL , S3. wal-e, wal-g - awscli . ?
( ): wal-g. wal-g. 40 wal-g . . , . , prefetch, wal , . , — , wal. wal , page cache , , wal, , . , .
: . , PostgreSQL — -> /dev/null, , . , . smoke . amcheck , . , , , .
: 10 . . . . wal — . ?
: . . . , .
: , pg_dump, . ?
: - . , .
: , , - ?
: pg_dump , .
: pg_dump, , , , , .
: , -, .
: , .
: , - .
: . . . . , , . . Pg_dump , - , exit_code . , , . , .
PS №1 pg_dump, pg_basebackup.
PS No. 2 Errores, correcciones según el artículo, las adiciones a la tabla dinámica se pueden hacer a través de la solicitud Pull
PS # 3 Wal-g da la bienvenida a voluntarios para ayudar con la documentación.
PS No. 4 Para instalar wal-g usando rpm, puede usar mi repositorio: Github , Fedora COPR .
PS No. 5 ¿Cómo hacer una copia de seguridad completa y una copia de seguridad incremental al crear y almacenar en S3 y guardar solo la copia de seguridad completa en cinta? Si tienes ideas, dímelo en los comentarios o en PM.
Encuesta: ¿Qué herramientas de respaldo usa?
PS No. 6 Canal de Telegram PostgreSQL: https://t.me/pgsql