Suxiro que lea a transcrición do informe de Andrey Borodin de principios de 2019 "Copias de seguranza con WAL-G. Que hai en 2019?"
Ola a todos! O meu nome é Andrey Borodin. Son programador en Yandex. Estou interesado en PostgreSQL desde 2016, despois de falar cos desenvolvedores e dixeron que todo é sinxelo: colle o código fonte e constrúeo e todo funcionará. E desde entón non podo parar: escribo todo tipo de cousas diferentes.
Unha das cousas nas que estou a traballar é un sistema de copia de seguridade. . En xeral, en Yandex levamos moito tempo traballando en sistemas de copia de seguridade en PostgreSQL. E podes atopar en Internet unha serie de seis informes sobre como facemos sistemas de copia de seguridade. E cada ano evolucionan un pouco, desenvólvense un pouco e fanse máis fiables.
Pero hoxe o informe non só trata do que fixemos, senón tamén do sinxelo que é e do que é. Cantos de vós xa viron os meus informes sobre WAL-G? É bo que non vira moita xente, porque vou comezar polo máis sinxelo.
Se de súpeto tes un clúster PostgreSQL e creo que todo o mundo ten un par deles con eles e, de súpeto, aínda non hai un sistema de copia de seguridade, entón tes que conseguir calquera almacenamento S3 ou compatible con Google Cloud.
Por exemplo, pode vir ao noso stand e levar un código promocional para Yandex Object Storage, que é compatible con S3.
A continuación, crea un balde. É só un recipiente para información.
Crear un usuario do servizo.
Crea unha clave de acceso para o usuario do servizo: aws-s3-key.
Descarga a última versión estable de WAL-G.
En que se diferencian os nosos prelanzamentos dos lanzamentos? Moitas veces pídenme que solte cedo. E se non hai ningún erro na versión durante un tempo suficiente, por exemplo, un mes, lánzoo. Aquí está este lanzamento de novembro. E isto significa que cada mes atopamos algún tipo de erro, normalmente en funcións non críticas, pero aínda non publicamos unha versión. A versión anterior é só novembro. Non hai erros coñecidos por nós, é dicir, engadíronse erros a medida que avanzaba o proxecto.
Unha vez que descargue o WAL-G, pode executar un simple comando de "lista de copia de seguridade", pasando as variables de ambiente. E conectarase a Object Storage e indicarache que copias de seguridade tes. Ao principio, por suposto, non deberías ter copias de seguridade. O obxectivo desta diapositiva é mostrar que todo é bastante sinxelo. Este é un comando de consola que acepta variables de ambiente e executa subcomandos.
Despois diso, podes facer a túa primeira copia de seguridade. Di "backup-push" en WAL-G e especifica en WAL-G a localización de pgdata do teu clúster. E o máis probable é que PostgreSQL che diga, se aínda non tes un sistema de copia de seguridade, que tes que activar o "modo de arquivo".
Isto significa que debes ir á configuración e activar "archive_mode = on" e engadir "archive_command", que tamén é un subcomando en WAL-G. Pero por algún motivo, a xente adoita usar scripts de barras sobre este tema e envolvelo en WAL-G. Por favor, non fagas isto. Use a funcionalidade que se atopa en WAL-G. Se che falta algo, escribe a . WAL-G asume que é o único programa que se executa en archive_command.
Usamos WAL-G principalmente para crear un clúster de alta dispoñibilidade na xestión da base de datos Yandex.
E normalmente úsase nunha topoloxía dun mestre e varias réplicas. Ao mesmo tempo, fai unha copia de seguridade en Yandex Object Storage.
Os escenarios máis comúns son a creación de copias dun clúster mediante a recuperación puntual. Pero neste caso, o rendemento do sistema de copia de seguridade non é tan importante para nós. Só necesitamos cargar un novo clúster desde a copia de seguridade.
Normalmente, necesitamos o rendemento do sistema de copia de seguridade ao engadir un novo nodo. Por que é importante? Normalmente a xente engade un novo nodo a un clúster porque o clúster existente non pode xestionar a carga de lectura. Deben engadir unha nova réplica. Se engadimos a carga de pg_basebackup ao mestre, entón o mestre pode colapsar. Polo tanto, era moi importante para nós que puidésemos cargar rapidamente un novo nodo do arquivo, creando unha carga mínima no Master.
E outra situación semellante. Esta é a necesidade de reiniciar o antigo Mestre despois de cambiar o Cluster Master do Data Center co que se perdeu a conectividade.
- Como resultado, ao formular os requisitos para o sistema de copia, decatámonos de que pg_basebackup non é axeitado para nós cando operamos na nube.
- Queriamos poder comprimir os nosos datos. Pero case calquera sistema de copia de seguridade que non sexa o que vén na caixa proporcionará compresión de datos.
- Queriamos paralelizar todo porque un usuario na nube compra un gran número de núcleos de procesador. Pero se non temos paralelismo nalgunha operación, entón un gran número de núcleos vólvese inútil.
- Necesitamos cifrado porque moitas veces os datos non son nosos e non se poden almacenar en texto claro. Por certo, a nosa contribución a WAL-G comezou co cifrado. Completamos o cifrado en WAL-G, despois de que nos preguntou: "Quizais algún de nós desenvolva o proxecto?" E dende entón levo máis dun ano traballando con WAL-G.
- Tamén necesitabamos limitar os recursos, porque co paso do tempo usando a nube, descubrimos que ás veces a xente ten unha carga importante de comestibles pola noite e esta carga non se pode interferir. É por iso que engadimos a limitación de recursos.
- Así como cotización e xestión.
- E verificación.
Observamos moitas ferramentas diferentes. Afortunadamente, temos unha gran selección en PostgreSQL. E en todas partes faltabamos algo, algunha pequena función, algunha pequena característica.
E despois de examinar os sistemas existentes, chegamos á conclusión de que imos desenvolver WAL-G. Era un proxecto novo entón. Foi bastante fácil influír no desenvolvemento cara á infraestrutura na nube do sistema de copia de seguridade.
A principal ideoloxía á que nos adherimos é que WAL-G debería ser tan sinxelo coma unha balalaika.
WAL-G ten 4 comandos. Isto:
WAL-PUSH: arquiva o eixe.
WAL-FETCH: obtén un eixe.
BACKUP-PUSH: fai unha copia de seguridade.
BACKUP-FETCH: obtén unha copia de seguridade do sistema de copia de seguridade.
De feito, WAL-G tamén ten xestión destas copias de seguridade, é dicir, listar e eliminar rexistros e copias de seguridade do historial que xa non son necesarios neste momento.
Unha das funcións importantes para nós é a función de crear copias delta.
As copias Delta significan que non creamos unha copia de seguridade completa de todo o clúster, senón só as páxinas modificadas dos ficheiros modificados do clúster. Parece que funcionalmente isto é moi semellante á capacidade de recuperar usando WAL. Pero podemos enrolar unha copia de seguridade delta dun fío único de WAL en paralelo. En consecuencia, cando temos unha copia de seguranza básica feita o sábado, copias de seguridade delta diariamente e o xoves fallamos, entón necesitamos acumular 4 copias de seguridade delta e 10 horas de WAL. Levará aproximadamente o mesmo tempo porque as copias de seguridade delta roldan en paralelo.
Deltas baseados en LSN: isto significa que ao crear unha copia de seguranza, necesitaremos combinar cada páxina e comprobar o seu LSN co LSN da copia de seguranza anterior para entender que cambiou. Calquera páxina que poida conter datos modificados debería estar presente na copia de seguridade delta.
Como dixen, prestouse moita atención ao paralelismo.
Pero a API de arquivo en PostgreSQL é coherente. PostgreSQL arquiva un ficheiro WAL e ao restauralo solicita un ficheiro WAL. Pero cando a base de datos solicita un ficheiro WAL mediante o comando "WAL-FETCH", chamamos ao comando "WAL-PREFETCH", que prepara os seguintes 8 ficheiros para obter datos do almacén de obxectos en paralelo.
E cando a base de datos nos pide que arquivemos un ficheiro, miramos archive_status e vemos se hai outros ficheiros WAL. E tamén estamos tentando descargar WAL en paralelo. Isto proporciona unha ganancia de rendemento significativa e reduce significativamente a distancia no número de WAL sen arquivar. Moitos desenvolvedores de sistemas de copia de seguridade cren que este é un sistema tan arriscado porque confiamos no noso coñecemento do código interno que non é a API de PostgreSQL. PostgreSQL non garante a presenza do cartafol archive_status para nós e non garante a semántica, a presenza de sinais de preparación para ficheiros WAL alí. Con todo, estamos estudando o código fonte, vemos que é así e intentamos explotalo. E controlamos a dirección na que se está a desenvolver PostgreSQL; se de súpeto este mecanismo se rompe, deixaremos de usalo.
Na súa forma pura, WAL delta baseado en LSN require ler calquera ficheiro de clúster cuxo tempo de modo no sistema de ficheiros cambiou desde a copia de seguridade anterior. Vivimos con isto durante moito tempo, case un ano. E ao final chegamos á conclusión de que temos deltas WAL.
Isto significa que cada vez que arquivamos WAL no Master, non só o comprimimos, o ciframos e o enviamos á rede, senón que tamén o lemos ao mesmo tempo. Analizamos e lemos os rexistros nel. Entendemos que bloques cambiaron e recollemos ficheiros delta.
Un ficheiro delta describe un determinado intervalo de ficheiros WAL, describe información sobre os bloques que se cambiaron neste intervalo de WAL. E entón estes ficheiros delta tamén se arquivan.
Aquí estamos ante o feito de que paralelizamos todo con bastante rapidez, pero non podemos ler un historial secuencial en paralelo, porque nun determinado segmento podemos atopar o final do rexistro anterior de WAL, co que aínda non temos nada que conectar, porque a lectura paralela levou a que primeiro analicemos o futuro, que aínda non ten pasado.
Como resultado, tivemos que poñer pezas incomprensibles en ficheiros _delta_parciais. Como resultado, cando volvamos ao pasado, pegaremos as pezas do rexistro de WAL nun, despois analizarémolo e comprenderemos o que cambiou nel.
Se no historial da análise do noso eixe hai polo menos un punto no que non entendemos o que estaba a suceder, entón, en consecuencia, durante a próxima copia de seguridade veremos obrigados a ler todo o clúster de novo, do mesmo xeito que fixemos cun LSN normal. -baseado en delta.
Como resultado, todo o noso sufrimento levou a que a biblioteca de análise WAL-G fose de código aberto. Que eu saiba, ninguén o está a usar aínda, pero se alguén quere, escríbeo e utilízao, é de dominio público. (Ligazón actualizada )
Como resultado, todos os fluxos de información parecen bastante complicados. O noso mestre arquiva o eixe e arquiva ficheiros delta. E a réplica que fai a copia de seguridade debe recibir ficheiros delta durante o tempo que pasou entre as copias de seguridade. Neste caso, hai que engadir e analizar partes do historial en masa, porque non todo o historial encaixa en grandes segmentos. E só despois diso, a réplica pode arquivar unha copia de seguridade delta completa.
Nas gráficas todo parece moito máis sinxelo. Esta é unha descarga dun dos nosos clusters reais. Temos baseado en LSN, feito nun día. E vemos que a copia de seguridade delta baseada en LSN funcionaba desde as tres da mañá ata as cinco da mañá. Esta é a carga no número de núcleos de procesador. WAL-delta levounos uns 20 minutos aquí, é dicir, fíxose significativamente máis rápido, pero ao mesmo tempo houbo un intercambio máis intenso pola rede.
Dado que temos información sobre que bloques cambiaron e en que momento no historial da base de datos, fomos máis aló e decidimos integrar a funcionalidade: unha extensión PostgreSQL chamada "pg_prefaulter".
Isto significa que cando a base en espera executa o comando de restauración, dille a WAL-G que busque o seguinte ficheiro WAL. Entendemos aproximadamente a que bloques de datos accederá o proceso de recuperación de WAL nun futuro próximo e iniciamos unha operación de lectura nestes bloques. Isto fíxose para aumentar o rendemento dos controladores SSD. Porque o rolo WAL chegará á páxina que hai que cambiar. Esta páxina está no disco e non está na caché da páxina. E agardará sincronizadamente a que chegue esta páxina. Pero preto está WAL-G, que sabe que nos próximos centos de megabytes de WAL necesitaremos determinadas páxinas e ao mesmo tempo comeza a quentalas. Inicia múltiples accesos ao disco para que se executen en paralelo. Isto funciona ben nas unidades SSD, pero, por desgraza, non é absolutamente aplicable a un disco duro, porque só interferimos con el coas nosas indicacións.
Isto é o que está agora no código.
Hai características que queremos engadir.
Esta imaxe mostra que WAL-delta leva un tempo relativamente curto. E isto é ler os cambios que se produciron na base de datos durante o día. Poderiamos facer WAL-delta non só pola noite, porque xa non é unha fonte importante de carga. Podemos ler WAL-delta cada minuto porque é barato. Nun minuto podemos analizar todos os cambios que se produciron no clúster. E isto podería chamarse "WAL-delta instantáneo".
A cuestión é que cando restauramos o clúster, reducimos o número de historias que temos que enrolar secuencialmente. É dicir, a cantidade de WAL que rola PostgreSQL debería reducirse, porque leva moito tempo.
Pero iso non é todo. Se sabemos que algún bloque se cambiará ata o punto de coherencia da copia de seguridade, non podemos cambialo no pasado. É dicir, agora temos a optimización ficheiro por ficheiro do reenvío WAL-delta. Isto significa que se, por exemplo, o martes se eliminou por completo algunha táboa ou algúns ficheiros foron eliminados por completo da táboa, entón cando o delta se transfire o luns e se restaure o pg_basebackup do sábado, nin sequera crearemos estes datos.
Queremos estender esta tecnoloxía ao nivel de páxina. É dicir, se algunha parte do ficheiro cambia o luns, pero se sobrescribirá o mércores, ao restaurar a un punto o xoves, non necesitaremos escribir as primeiras versións das páxinas no disco.
Pero esta aínda é unha idea que se está a discutir activamente dentro de nós, pero aínda non chegou ao código.
Queremos facer unha función máis en WAL-G. Queremos facelo extensible porque necesitamos soportar diferentes bases de datos e gustaríanos poder abordar a xestión de copias de seguridade do mesmo xeito. Pero o problema é que as API de MySQL son radicalmente diferentes. En MySQL, PITR non se basea no rexistro físico WAL, senón no binlog. E non temos un sistema de arquivo en MySQL que lle diga a algún sistema externo que este binlog está rematado e que debe ser arquivado. Necesitamos estar nalgún lugar de cron coa base de datos e comprobar se hai algo preparado?
E do mesmo xeito, durante unha restauración de MySQL, non hai ningún comando de restauración que poida indicarlle ao sistema que necesito tal ou tal ficheiro. Antes de comezar a reconstruír o clúster, debes saber que ficheiros necesitarás. Ti mesmo debes adiviñar que ficheiros necesitarás. Pero estes problemas poden ser evitados dalgún xeito. (Aclaración: MySQL xa está soportado)
No informe, tamén quería falar deses casos nos que WAL-G non é axeitado para vostede.
Se non tes unha réplica síncrona, WAL-G non garante que o último segmento se conserve. E se o arquivo está por detrás dos últimos segmentos da historia, iso é un risco. Se non hai réplica síncrona, non recomendaría usar WAL-G. Aínda así, está pensado principalmente para unha instalación na nube, o que implica unha solución de Alta Dispoñibilidade cunha réplica síncrona, que se encarga da seguridade dos últimos bytes comprometidos.
Moitas veces vexo xente intentando executar WAL-G e WAL-E ao mesmo tempo. Admitimos a compatibilidade con versións anteriores no sentido de que WAL-G pode restaurar un ficheiro de WAL-E e pode restaurar unha copia de seguridade feita en WAL-E. Pero como ambos sistemas usan wal-push paralelo, comezan a roubar ficheiros entre si. Se o corriximos en WAL-G, aínda permanecerá en WAL-E. En WAL-E, mira o estado do arquivo, ve os ficheiros rematados e arquivaos, mentres que outros sistemas simplemente non saben que existe este ficheiro WAL, porque PostgreSQL non tentará arquivalo por segunda vez.
Que imos arranxar aquí no lado de WAL-G? Non informaremos a PostgreSQL de que este ficheiro foi transferido en paralelo, e cando PostgreSQL nos pida que o arquiveremos, xa saberemos que tal ficheiro con este modo-time e con este md5 xa foi arquivado e simplemente diremos PostgreSQL - OK, todo está listo sen facer nada.
Pero é pouco probable que este problema se solucione no lado de WAL-E, polo que actualmente é imposible crear un comando de arquivo que arquive o ficheiro tanto en WAL-G como en WAL-E.
Ademais, hai casos nos que WAL-G non é axeitado para ti agora, pero definitivamente o solucionaremos.
En primeiro lugar, actualmente non temos unha verificación de copia de seguranza integrada. Non temos verificación nin durante a copia de seguridade nin a recuperación. Por suposto, isto está implementado na nube. Pero isto implícase simplemente mediante unha comprobación previa, simplemente restaurando o clúster. Gustaríame ofrecer esta funcionalidade aos usuarios. Pero por verificación, supoño que en WAL-G será posible restaurar o clúster e inicialo, e realizar probas de fume: pg_dumpall to /dev/null e amcheck index verification.
Actualmente en WAL-G non hai forma de aprazar unha copia de seguridade de WAL. É dicir, admitimos algunha fiestra. Por exemplo, almacenar os últimos sete días, almacenar as últimas dez copias de seguranza, almacenar as tres últimas copias de seguridade completas. Moitas veces a xente vén e di: "Necesitamos unha copia de seguridade do que pasou o ano novo e queremos mantelo para sempre". WAL-G aínda non pode facelo. (Nota: isto xa se solucionou. Ler máis: opción de marca de copia de seguranza en )
E non dispoñemos de sumas de verificación de páxinas e de comprobacións de integridade para todos os segmentos do eixe ao validar PITR.
De todo isto elaborei un proxecto para Google Summer of Code. Se coñeces estudantes intelixentes aos que lles gustaría escribir algo en Go e obter varios miles de dólares dunha empresa coa letra "G", recoméndalles o noso proxecto. Vou facer de mentor deste proxecto, eles poden facelo. Se non hai alumnos, entón vouno levar e facelo eu no verán.
E temos moitos outros pequenos problemas nos que pouco a pouco imos traballando. E ocorren cousas bastante estrañas.
Por exemplo, se dás a WAL-G unha copia de seguridade baleira, simplemente caerá. Por exemplo, se lle dis que necesita facer unha copia de seguridade dun cartafol baleiro. O ficheiro pg_control non estará alí. E pensará que non entende algo. En teoría, neste caso cómpre escribir unha mensaxe normal ao usuario para explicarlle como utilizar a ferramenta. Pero isto nin sequera é unha característica da programación, senón unha característica dunha boa linguaxe intelixible.
Non sabemos como facer unha copia de seguranza sen conexión. Se a base de datos está mentindo, non podemos facer unha copia de seguridade dela. Pero aquí todo é moi sinxelo. Chamamos copias de seguridade por LSN cando comezou. O LSN da base subxacente debe lerse desde o ficheiro de control. E esta é unha característica tan non realizada. Moitos sistemas de copia de seguridade poden facer unha copia de seguridade dunha base de datos subxacente. E é conveniente.
Actualmente non podemos xestionar correctamente a falta de espazo de copia de seguranza. Porque normalmente traballamos con grandes copias de seguridade na casa. E non chegaron a iso. Pero se alguén quere programar en Go agora mesmo, engade o tratamento dos erros de fóra de espazo ao depósito. Definitivamente mirarei a solicitude de extracción.
E o principal que nos preocupa é que queremos tantas probas de integración do docker como sexa posible que verifiquen varios escenarios. Nestes momentos só estamos probando escenarios básicos. En cada commit, pero queremos comprobar commit por commit todas as funcionalidades que admitimos. En particular, por exemplo, teremos soporte suficiente para PostgreSQL 9.4-9.5. Apoiámolos porque a comunidade admite PostgreSQL, pero non comprobamos commit-by-commit para asegurarnos de que todo non está roto. E paréceme que este é un risco bastante grave.
Temos WAL-G funcionando en máis de mil clústeres na xestión de bases de datos Yandex. E fai unha copia de seguranza de varios centos de terabytes de datos todos os días.
Temos moitas tarefas por facer no noso código. Se queres programar, ven, agardamos solicitudes de pull, agardamos dúbidas.
preguntas
Boas tardes! Grazas! Supoño que se estás a usar WAL-delta, probablemente esteas a depender moito das escrituras de páxina completa. E se é así, fixeches probas? Mostraches un bonito gráfico. Canto máis fermoso se fai se a FPW está desactivada?
As escrituras a páxina completa están habilitadas para nós, non intentamos desactivalas. É dicir, eu, como programador, non tentei desactivalo. Os administradores do sistema que investigaron probablemente investigaron este problema. Pero necesitamos FPW. Case ninguén o desactiva, porque se non é imposible facer unha copia de seguridade dunha réplica.
Grazas polo informe! Teño dúas preguntas. A primeira pregunta é que pasará cos espazos de táboa?
Estamos agardando unha solicitude de extracción. As nosas bases de datos viven en discos SSD e NMVE e realmente non necesitamos esta función. Non estou preparado para dedicar moito tempo agora mesmo a facelo ben. Defendo de todo corazón que apoiemos isto. Hai xente que o apoiou, pero o apoiou dun xeito que lles convén. Fixeron un garfo, pero non fan solicitudes de tiro. (Engadido na versión 0.2.13)
E a segunda pregunta. Vostede dixo ao principio que WAL-G asume que funciona só e que non se necesitan envoltorios. Eu mesmo uso envoltorios. Por que non deberían usarse?
Queremos que sexa tan sinxelo coma unha balalaika. Isto significa que non necesitas nada, excepto unha balalaika. Queremos que o sistema sexa sinxelo. Se tes unha funcionalidade que necesitas facer nun script, ven e cóntanos: farémolo en Go.
Boas tardes! Grazas polo informe! Non puidemos facer que WAL-G funcione co descifrado GPG. Cifra normalmente, pero non quere descifrar. É algo que non nos resultou? A situación é deprimente.
Crea un problema en GitHub e resolvémolo.
É dicir, non atopaches isto?
Hai unha característica do informe de erro que, cando WAL-G non entende que tipo de ficheiro é, pregunta: "Quizais estea cifrado?" Quizais o problema non sexa o cifrado. Quero mellorar o rexistro deste tema. Debe descifralo. Actualmente estamos traballando neste tema no sentido de que non nos gusta moito como está organizado o sistema de obtención de claves públicas e privadas. Porque chamamos GPG externo para que nos dea as súas claves. E despois collemos estas claves e trasladámolas ao GPG interno, que é PGP aberto, que se compila para nós dentro de WAL-G, e alí chamamos cifrado. Neste sentido, queremos mellorar o sistema e queremos admitir o cifrado Libsodium (Engadido na versión 0.2.15). Por suposto, a decodificación debería funcionar, imos descubrilo: necesitas máis un síntoma que un par de palabras. Podes reunirte na sala do altofalante nalgún momento e mirar o sistema. (Cifrado PGP sen GPG externo - v0.2.9)
Ola! Grazas polo informe! Teño dúas preguntas. Teño un estraño desexo de iniciar sesión pg_basebackup e WAL en dous provedores, é dicir, quero facer unha nube e outra. Hai algunha maneira de facelo?
Isto non existe agora, pero é unha idea interesante.
Simplemente non confío nun provedor, quero ter o mesmo noutro, por se acaso.
A idea é interesante. Tecnicamente, isto non é nada difícil de implementar. Para evitar que se perda a idea, podo pedirche que fagas un problema en GitHub?
Si, claro.
E despois, cando os estudantes veñan a Google Summer of Code, engadirémolos ao proxecto para que haxa máis traballo para sacarlles máis proveito.
E a segunda pregunta. Hai un problema en GitHub. Creo que xa está pechado. Hai pánico durante a restauración. E para derrotalo, fixeches unha asemblea separada. É certo nos temas. E hai unha opción para facer un ambiente variable nun fío. E por iso funciona moi lentamente. E atopamos este problema e aínda non se solucionou.
O problema é que por algún motivo o almacenamento (CEPH) restablece a conexión cando chegamos a el con alta concorrencia. Que se pode facer ao respecto? A lóxica de reintento ten este aspecto. Estamos tentando descargar o ficheiro de novo. Nunha pasada, tivemos unha serie de ficheiros sen descargar, faremos un segundo para todos aqueles que non iniciaron sesión. E mentres se cargue polo menos un ficheiro por iteración, repetimos e repetimos e repetimos. Melloramos a lóxica do reintento: retroceso exponencial. Pero non está do todo claro que facer co feito de que a conexión simplemente se rompa no lado do sistema de almacenamento. É dicir, cando subimos a unha emisión, non rompe estas conexións. Que podemos mellorar aquí? Temos limitación de rede, podemos limitar cada conexión polo número de bytes que envía. Se non, non sei como xestionar o feito de que o almacenamento de obxectos non nos permite descargar ou descargar desde el en paralelo.
Sen SLA? Non está escrito para eles como se deixan atormentar?
A cuestión é que as persoas que veñen con esta pregunta adoitan ter a súa propia bóveda. É dicir, ninguén procede de Amazon nin de Google Cloud, nin de Yandex Object Storage.
Quizais a pregunta xa non é para ti?
A pregunta aquí neste caso non importa a quen. Se hai algunha idea sobre como tratar con isto, imos facelo en WAL-G. Pero ata agora non teño boas ideas sobre como tratar con isto. Hai algúns obxectos de almacenamento que admiten listas de copias de seguridade de forma diferente. Pídelles que enumeren obxectos e eles engaden cartafol alí. WAL-G ten medo por isto: hai algún tipo de cousa aquí que non é un ficheiro, non podo restauralo, o que significa que non se restaurou a copia de seguridade. É dicir, de feito, tes un clúster completamente restaurado, pero devolveche un estado erróneo porque Object Storage devolveu información estraña que non entendeu completamente.
Isto é algo que ocorre na nube de correo.
Se podes construír unha reprodución...
Reprodúcese constantemente...
Se hai unha reprodución, creo que experimentaremos con estratexias de reintento e descubriremos como tentar de novo e comprender o que a nube nos require. Quizais sexa estable para nós en tres conexións e non rompa a conexión, entón chegaremos a tres con coidado. Porque agora eliminamos a conexión moi rápido, é dicir, se iniciamos unha recuperación con 16 fíos, despois do primeiro reintento haberá 8 fíos, 4 fíos, 2 fíos e un. E entón tirará o ficheiro nun fluxo. Se hai algúns valores máxicos como 7,5 fíos son os mellores para bombear, entón deterémonos neles e tentaremos facer outros 7,5 fíos. Aquí tes unha idea.
Grazas polo informe! Como é un fluxo de traballo completo para traballar con WAL-G? Por exemplo, no caso estúpido cando non hai delta entre páxinas. E tomamos e eliminamos a copia de seguridade inicial, despois arquivamos o eixe ata que esteamos azules na cara. Aquí, segundo o entendo, hai unha avaría. Nalgún momento cómpre facer unha copia de seguridade delta das páxinas, é dicir, algún proceso externo está a impulsar isto ou como ocorre isto?
A API de copia de seguridade delta é bastante sinxela. Hai un número alí: pasos delta máximos, así se chama. Por defecto é cero. Isto significa que cada vez que fai unha copia de seguridade, descarga unha copia de seguridade completa. Se o cambias a calquera número positivo, por exemplo, 3, a próxima vez que fagas unha copia de seguridade, verá o historial de copias de seguridade anteriores. Ve que non superas a cadea de 3 deltas e fai un delta.
É dicir, cada vez que lanzamos WAL-G, tenta facer unha copia de seguridade completa?
Non, executamos WAL-G e tenta crear un delta se as túas políticas o permiten.
En liñas xerais, se o executas con cero cada vez, comportarase como pg_basebackup?
Non, aínda funcionará máis rápido porque usa compresión e paralelismo. Pg_basebackup poñerá o eixe ao teu lado. WAL-G asume que tes o arquivo configurado. E emitirá un aviso se non está configurado.
Pg_basebackup pódese executar sen eixes.
Si, entón se comportarán case igual. Pg_basebackup cópiase ao sistema de ficheiros. Por certo, temos unha nova función que esquecín mencionar. Agora podemos facer unha copia de seguridade no sistema de ficheiros desde pg_basebackup. Non sei por que fai falta, pero está aí.
Por exemplo, en CephFS. Non todos queren configurar o almacenamento de obxectos.
Si, probablemente por iso fixeron unha pregunta sobre esta función para que puidésemos facelo. E fixémolo.
Grazas polo informe! Só hai unha pregunta sobre a copia no sistema de ficheiros. Fóra da caixa, agora admites a copia no almacenamento remoto, por exemplo, se hai algún estante no centro de datos ou outra cousa?
Nesta formulación, esta é unha pregunta difícil. Si, apoiamos, pero esta funcionalidade aínda non está incluída en ningunha versión. É dicir, todas as versións previas admiten isto, pero as versións do lanzamento non. Esta funcionalidade engadiuse na versión 0.2. Definitivamente será lanzado en breve, en canto solucionemos todos os erros coñecidos. Pero agora mesmo isto só se pode facer na prelanzamento. Hai dous erros no prelanzamento. Problema coa recuperación de WAL-E, non o solucionamos. E na última versión previa engadiuse un erro sobre a copia de seguranza delta. Polo tanto, recomendamos a todos que utilicen as versións de lanzamento. En canto non haxa máis erros no prelanzamento, podemos dicir que admitimos Google Cloud, cousas compatibles con S3 e almacenamento de ficheiros.
Ola, grazas polo informe. Segundo o entendo, WAL-G non é unha especie de sistema centralizado como os barmen? Pensas avanzar nesta dirección?
O problema é que nos afastamos desta dirección. WAL-G vive no host base, no host do clúster e en todos os hosts do clúster. Cando nos mudamos a varios miles de grupos, tiñamos moitas instalacións de barman. E cada vez que algo se desmorona neles, é un gran problema. Debido a que necesitan ser reparados, cómpre comprender que clústeres agora non teñen copias de seguridade. Non penso desenvolver WAL-G na dirección de hardware físico para sistemas de copia de seguridade. Se a comunidade quere algunha funcionalidade aquí, non me importa nada.
Temos equipos que se encargan do almacenamento. E sentímonos tan ben que non somos nós, que hai persoas especiais que poñen os nosos ficheiros onde os ficheiros están seguros. Eles fan todo tipo de codificación intelixente alí para soportar a perda dun certo número de ficheiros. Son responsables do ancho de banda da rede. Cando tes un barman, podes descubrir de súpeto que no mesmo servidor xuntáronse pequenas bases de datos con moito tráfico. Parece que tes moito espazo, pero por algún motivo non cabe todo a través da rede. Pode resultar ao revés. Hai moitas redes alí, hai núcleos de procesador, pero aquí non hai discos. E cansámonos desta necesidade de facer malabarismos con algo, e pasamos ao feito de que o almacenamento de datos é un servizo separado, do que son responsables persoas especiais separadas.
PS Unha nova versión foi lanzada , no que pode usar o ficheiro de configuración .walg.json, que se atopa no directorio de inicio de postgres por defecto. Podes abandonar os scripts bash. O exemplo .walg.json está neste problema
Vídeo:
Fonte: www.habr.com