Suxiro que lea a transcrición do informe de principios de 2020 de Georgy Rylov "WAL-G: novas oportunidades e expansión da comunidade"
Os mantedores de código aberto afrontan moitos retos a medida que medran. Como escribir cada vez máis funcións necesarias, solucionar cada vez máis problemas e conseguir ver máis e máis solicitudes de extracción? Usando WAL-G (ferramenta de copia de seguridade para PostgreSQL) como exemplo, contarei como resolvemos estes problemas lanzando un curso sobre Desenvolvemento de código aberto na universidade, o que conseguimos e cara a onde nos moveremos a continuación.
Ola de novo a todos! Son un programador Yandex de Ekaterimburgo. E hoxe falarei de WAL-G.
O título do informe non dicía que se tratase de copias de seguridade. Alguén sabe o que é WAL-G? Ou todo o mundo sabe? Levante a man se non o sabe. Caramba, viñeches ao informe e non sabes de que se trata.
Déixame contar o que vai pasar hoxe. Ocorre que o noso equipo leva bastante tempo facendo copias de seguridade. E este é outro informe dunha serie onde falamos de como almacenamos os datos de forma segura, segura, cómoda e eficiente.
Nas series anteriores houbo moitos informes de Andrei Borodin e Vladimir Leskov. Eramos moitos. E levamos moitos anos falando de WAL-G.
clck.ru/F8ioz —
clck.ru/Ln8Qw —
Este informe será un pouco diferente dos demais xa que se trataba máis da parte técnica, pero aquí falarei de como nos atopamos con problemas asociados ao crecemento da comunidade. E como se nos ocorreu unha pequena idea que nos axuda a afrontar isto.
Hai uns anos, WAL-G era un proxecto bastante pequeno que obtivemos de Citus Data. E só o levamos. E foi desenvolvido por unha persoa.
E só WAL-G non tiña:
- Copia de seguranza dunha réplica.
- Non houbo copias de seguranza incrementais.
- Non houbo copias de seguridade de WAL-Delta.
- E aínda faltaba moito.
Ao longo destes anos, WAL-G medrou moito.
E para 2020, todo o anterior xa apareceu. E a isto sumouse o que agora temos:
- Máis de 1 estrelas en GitHub.
- 150 garfos.
- Uns 15 PR abertos.
- E moitos máis colaboradores.
- E temas abertos todo o tempo. E iso a pesar de que literalmente imos alí todos os días e facemos algo ao respecto.
E chegamos á conclusión de que este proxecto require máis da nosa atención, mesmo cando nós mesmos non necesitamos implementar nada para o noso servizo de bases de datos xestionadas en Yandex.
E nalgún lugar no outono de 2018 veunos unha idea á cabeza. Normalmente o equipo ten varias formas de desenvolver algunhas funcións ou corrixir erros se non tes mans suficientes. Por exemplo, pode contratar outro programador e pagarlle diñeiro. Ou podes contratar un pasante por un tempo e tamén pagarlle un soldo. Pero aínda hai un grupo bastante grande de persoas, algunhas das cales xa saben realmente escribir código. Non sempre sabes cal é a calidade do código.
Pensámolo e decidimos tentar atraer alumnos. Pero os alumnos non participarán en todo connosco. Só farán parte do traballo. E, por exemplo, escribirán probas, corrixirán erros, implementarán funcións que non afectan á funcionalidade principal. A principal función é crear copias de seguridade e restaurar copias de seguridade. Se cometemos un erro ao crear unha copia de seguridade, experimentaremos a perda de datos. E ninguén quere isto, claro. Todo o mundo quere que todo sexa moi seguro. Polo tanto, por suposto, non queremos deixar código no que confiamos menos que o noso. É dicir, calquera código non crítico é o que nos gustaría recibir dos nosos traballadores adicionais.
En que condicións se aceptan PR dos estudantes?
- Están obrigados a cubrir o seu código con probas. Todo debería ter lugar en CI.
- E tamén pasamos por 2 críticas. Un de Andrey Borodin e outro de min.
- E ademais, para comprobar que isto non romperá nada no noso servizo, subo por separado a montaxe con este commit. E comprobamos nas probas de extremo a extremo que nada falla.
Curso especial de código aberto
Un pouco sobre por que é necesario isto e por que isto, paréceme, é unha idea xenial.
Para nós, o beneficio é obvio:
- Temos máis mans.
- E estamos a buscar candidatos para o equipo entre estudantes intelixentes que escriben código intelixente.
Cal é o beneficio para os estudantes?
Poden ser menos evidentes, porque os estudantes, como mínimo, non reciben cartos polo código que escriben, senón que só reciben cualificacións dos seus expedientes.
Pregunteille por isto. E nas súas palabras:
- Experiencia de colaborador en código aberto.
- Obtén unha liña no teu CV.
- Demostra a ti mesmo e pasa unha entrevista en Yandex.
- Faite membro do GSoC.
- +1 curso especial para aqueles que queiran escribir código.
Non vou falar de como se estruturaba o curso. Só direi que WAL-G foi o proxecto principal. Tamén incluímos neste curso proxectos como Odyssey, PostgreSQL e ClickHouse.
E deron problemas non só neste curso, senón que tamén entregaron diplomas e traballos de curso.
E o beneficio para os usuarios?
Agora imos pasar á parte que máis che interesa. De que che serve isto? A cuestión é que os alumnos solucionaron moitos erros. E fixemos as funcións de solicitude que nos pediches.
E permíteme falarche das cousas que desde hai tempo querías e que se realizaron.
Soporte de tablespaces. Espéranse espazos de táboa en WAL-G probablemente desde o lanzamento de WAL-G, porque WAL-G é o sucesor doutra ferramenta de copia de seguridade WAL-E, onde se admitían as copias de seguridade de bases de datos con espazos de táboa.
Permíteme recordarche brevemente o que é e por que é necesario. Normalmente, todos os teus datos de Postgres ocupan un directorio do sistema de ficheiros, chamado base. E este directorio xa contén todos os ficheiros e subdirectorios requiridos por Postgres.
Os espazos de táboa son directorios que conteñen datos de Postgres, pero non están situados fóra do directorio base. A diapositiva mostra que os tablespacs están situados fóra do directorio base.
Como é isto para o propio Postgres? Hai un subdirectorio separado pg_tblspc no directorio base. E contén ligazóns simbólicas a directorios que realmente conteñen datos de Postgres fóra do directorio base.
Cando usas todo isto, entón para ti estes comandos poden parecer algo así. É dicir, crea unha táboa nalgún espazo de táboa especificado e ve onde está agora. Estas son as dúas últimas liñas, as dúas últimas ordes chamadas. E aí está claro que hai algún camiño. Pero en realidade, este non é o camiño real. Este é o camiño prefixado desde o directorio base ata o espazo de táboa. E a partir de aí combínase cunha ligazón simbólica que conduce aos teus datos reais.
Non usamos todo isto no noso equipo, pero foi usado por moitos outros usuarios de WAL-E que nos escribiron dicindo que querían pasar a WAL-G, pero isto os estaba a impedir. Agora é compatible.
Outra característica que nos trouxo o noso curso especial é o catchup. As persoas que probablemente traballaron máis con Oracle que con Postgres saben sobre catchup.
Brevemente sobre o que é. A topoloxía do clúster do noso servizo normalmente pode parecer algo así. Temos un mestre. Hai unha réplica que transmite o rexistro de escritura anticipada. E a réplica dille ao mestre en que LSN está actualmente. E nalgún lugar paralelo a isto, pódese arquivar o rexistro. E ademais de arquivar o rexistro, tamén se envían copias de seguridade á nube. E envíanse copias de seguridade delta.
Cal podería ser o problema? Cando tes unha base de datos bastante grande, pode resultar que a túa réplica comeza a quedar moi atrás do mestre. E queda tan atrasada que nunca pode alcanzar el. Este problema xeralmente debe ser resolto dalgún xeito.
E o xeito máis doado é eliminar a réplica e cargala de novo, porque nunca chegará ao día e hai que solucionar o problema. Pero isto é moito tempo, porque restaurar unha copia de seguridade da base de datos completa de 10 TB é un tempo moi, moi longo. E queremos facer todo isto o máis rápido posible se xorden tales problemas. E para iso é exactamente o catchup.
Catchup permítelle utilizar copias de seguridade delta, que se almacenan na nube deste xeito. Di en cal LSN está actualmente a réplica atrasada e especifícao no comando catchup para crear unha copia de seguridade delta entre ese LSN e o LSN no que se atopa actualmente o seu clúster. E despois restauras esta copia de seguridade na réplica que estaba atrasada.
Outras bases
O alumnado tamén nos trouxo moitas características á vez. Dado que en Yandex non só cociñamos Postgres, tamén temos MySQL, MongoDB, Redis, ClickHouse, nalgún momento necesitabamos poder facer copias de seguridade con recuperación puntual para MySQL, e así houbese oportunidade de cargar á nube.
E queriamos facelo dun xeito semellante ao que fai WAL-G. E decidimos experimentar e ver como quedaría todo.
E ao principio, sen compartir esta lóxica de ningún xeito, escribiron o código no fork. Viron que temos algún tipo de modelo de traballo e que pode voar. Entón pensamos que a nosa comunidade principal son os postgresistas, eles usan WAL-G. E, polo tanto, necesitamos separar estas partes dalgún xeito. É dicir, cando editamos código para Postgres, non rompemos MySQL; cando editamos MySQL, non rompemos Postgres.
A primeira idea sobre como separar isto foi a idea de usar o mesmo enfoque que se usa nas extensións PostgreSQL. E, de feito, para facer unha copia de seguridade de MySQL había que instalar algún tipo de biblioteca dinámica.
Pero aquí a asimetría deste enfoque é inmediatamente visible. Cando fas unha copia de seguridade de Postgres, pons unha copia de seguridade normal de Postgres e todo está ben. E para MySQL resulta que instalas unha copia de seguridade para Postgres e tamén instalas unha biblioteca dinámica para MySQL para iso. Parece estraño. Nós tamén o pensamos e decidimos que esta non era a solución que necesitabamos.
Varias compilacións para Postgres, MySQL, MongoDB, Redis
Pero isto permitiunos, nos parece, tomar a decisión correcta: asignar diferentes asembleas para diferentes bases. Isto permitiu illar a lóxica vinculada ás copias de seguridade de varias bases de datos que accederán á API común que implementa WAL-G.
Esta é a parte que nós mesmos escribimos - antes de darlle aos alumnos os problemas. É dicir, esta é exactamente a parte na que poderían facer algo mal, así que decidimos que era mellor que fixeramos algo así e que todo irá ben.
Despois diso demos problemas. Foron inmediatamente desmantelados. Os estudantes debían apoiar tres bases.
Este é MySQL, que levamos máis dun ano facendo unha copia de seguridade usando WAL-G deste xeito.
E agora MongoDB achégase á produción, onde a están rematando cun ficheiro. De feito, nós escribimos o marco para todo isto. Despois os alumnos escribiron algunhas cousas viables. E despois traémolos a un estado que podemos aceptar na produción.
Estes problemas non parecían que os estudantes necesitasen escribir ferramentas de copia de seguridade completas para cada unha destas bases de datos. Non tivemos tal problema. O noso problema era que queriamos unha recuperación puntual e queriamos facer unha copia de seguridade na nube. E pedíronlles aos estudantes que escribisen algún código que resolva isto. Os estudantes utilizaron ferramentas de copia de seguridade xa existentes, que dalgún xeito realizan copias de seguridade, e despois pegárono todo con WAL-G, que o reenviou todo á nube. E tamén engadiron a isto unha recuperación puntual.
Que máis trouxeron os alumnos? Eles trouxeron soporte de cifrado Libsodium a WAL-G.
Tamén temos políticas de almacenamento de backup. Agora as copias de seguridade pódense marcar como permanentes. E dalgún xeito é máis cómodo para o teu servizo automatizar o proceso de almacenalos.
Cal foi o resultado deste experimento?
Máis de 100 persoas rexistráronse inicialmente no curso. Nun principio non dixen que a universidade de Ekaterimburgo sexa a Universidade Federal dos Urales. Alí anunciamos todo. 100 persoas inscritas. En realidade, moita menos xente comezou a facer algo, unhas 30 persoas.
Aínda menos persoas completaron o curso, porque foi necesario facer probas para os códigos que xa existen. E tamén corrixir algún erro ou facer algunha función. E algúns alumnos aínda pecharon o curso.
Actualmente, durante este curso, os alumnos solucionaron uns 14 problemas e fixeron 10 funcións de varios tamaños. E, paréceme, esta é unha substitución total dun ou dous desenvolvedores.
Entre outras cousas, entregamos diplomas e traballos de curso. E 12 recibiron diplomas. 6 deles xa se defenderon en “5”. Os que quedaron aínda non tiñan protección, pero penso que tamén lles irá todo ben.
Planos para o futuro
Que plans temos para o futuro?
Polo menos aquelas solicitudes de funcións que xa escoitamos dos usuarios e que queremos facer. Isto:
- Supervisar a corrección do seguimento da liña de tempo no arquivo de copia de seguridade do clúster de alta disponibilidad. Podes facelo con WAL-G. E creo que teremos estudantes que se ocuparán deste asunto.
- Xa temos un responsable de transferir copias de seguridade e WAL entre nubes.
- E publicamos recentemente unha idea de que podemos acelerar WAL-G aínda máis descomprimindo copias de seguridade incrementais sen reescribir páxinas e optimizar os arquivos que enviamos alí.
Podes compartilos aquí
Para que serviu este informe? Ademais, agora, ademais das 4 persoas que apoian este proxecto, temos mans adicionais, das que hai bastantes. Sobre todo se lles escribes nunha mensaxe persoal. E se fas unha copia de seguranza dos teus datos e faino usando WAL-G ou queres pasar a WAL-G, poderemos satisfacer os teus desexos facilmente.
Este é un código QR e unha ligazón. Podes pasar por eles e escribir todos os teus desexos. Por exemplo, non estamos corrixindo algún erro. Ou realmente queres algunha función, pero por algún motivo aínda non está en ningunha copia de seguridade, incluída a nosa. Asegúrate de escribir sobre isto.
preguntas
Ola! Grazas polo informe! Pregunta sobre WAL-G, pero non sobre Postgres. WAL-G fai unha copia de seguranza de MySQL e fai unha copia de seguridade adicional. Se tomamos instalacións modernas en CentOS e se instalas ñam MySQL, instalarase MariDB. A partir da versión 10.3 non se admite a copia de seguranza adicional, a copia de seguranza MariDB é compatible. Como estás con isto?
Polo momento non tentamos facer unha copia de seguridade de MariDB. Tivemos solicitudes de soporte de FoundationDB, pero en xeral, se hai tal solicitude, podemos atopar persoas que o fagan. Non é tan longo nin tan difícil como penso.
Boas tardes Grazas polo informe! Pregunta sobre posibles novas funcións. Estás preparado para facer que WAL-G funcione con cintas para poder facer copias de seguridade en cintas?
Copia de seguranza no almacenamento en cinta significa aparentemente?
Si
Está Andrei Borodin, que pode responder esta pregunta mellor ca min.
(Andrey) Si, grazas pola pregunta! Tivemos unha solicitude para transferir unha copia de seguranza a unha cinta desde o almacenamento na nube. E para iso transferencia entre nubes. Porque a transferencia de nube a nube é unha versión xeneralizada da transferencia de cinta. Ademais, temos unha arquitectura extensible en canto a Almacenamentos. Por certo, moitos Storoges foron escritos por estudantes. E se escribe Almacenamento para cinta, será compatible, por suposto. Estamos preparados para considerar as solicitudes de retirada. Alí cómpre escribir un ficheiro, ler un ficheiro. Se fas estas cousas en Go, normalmente acabas con 50 liñas de código. E entón a cinta será compatible con WAL-G.
Grazas polo informe! Interesante proceso de desenvolvemento. A copia de seguranza é unha función seria que debería estar ben cuberta polas probas. Cando implementou a funcionalidade para novas bases de datos, os estudantes tamén escribiron as probas, ou escribiu vostede mesmo as probas e despois deu a implementación aos estudantes?
Os estudantes tamén escribiron probas. Pero os estudantes escribiron máis para funcións como novas bases de datos. Escribiron probas de integración. E escribiron probas unitarias. Se a integración pasa, é dicir, neste momento, este é un script que executas manualmente ou tes cron facéndoo, por exemplo. É dicir, o guión alí está moi claro.
Os estudantes non teñen moita experiencia. A revisión leva moito tempo?
Si, as críticas levan moito tempo. É dicir, normalmente, cando varios comisarios veñen á vez e din que eu fixen isto, fixen iso, entón hai que pensar e reservar medio día para descubrir o que escribiron alí. Porque o código hai que ler con atención. Non tiveron unha entrevista. Non os coñecemos moi ben, polo que leva moito tempo.
Grazas polo informe! Anteriormente, Andrey Borodin afirmou que archive_command en WAL-G debería chamarse directamente. Pero no caso dalgún tipo de cartucho de clúster, necesitamos lóxica adicional para determinar o nodo desde o que enviar os eixes. Como resolves este problema ti mesmo?
Cal é o teu problema aquí? Digamos que tes unha réplica sincrónica coa que estás facendo unha copia de seguridade? Ou que?
(Andrey) O feito é que WAL-G está pensado para ser usado sen scripts de shell. Se falta algo, engademos a lóxica que debería estar dentro de WAL-G. En canto a onde debería proceder o arquivado, cremos que o arquivado debería proceder do mestre actual do clúster. Arquivar a partir dunha réplica é unha mala idea. Hai varios escenarios posibles con problemas. En particular, problemas co arquivo de cronogramas e calquera información adicional. Grazas pola pregunta!
(Aclaración: desfixémonos dos scripts de shell )
Boas tardes! Grazas polo informe! Estou interesado na función de recuperación da que falaches. Atopámonos cunha situación na que unha réplica estaba atrás e non podía poñerse ao día. E non atopei unha descrición desta función nos documentos de WAL-G.
Catchup apareceu literalmente o 20 de xaneiro de 2020. A documentación pode necesitar algo máis de traballo. Escribimos nós mesmos e non o escribimos moi ben. E quizais deberíamos comezar a esixirlle aos estudantes que o escriban.
Xa está lanzado?
A solicitude de extracción xa está morta, é dicir, comprobeino. Probei isto nun clúster de proba. Ata agora non tivemos unha situación na que puidésemos probar isto nun exemplo de combate.
Cando esperar?
Non sei. Agarda un mes, comprobarémolo con certeza.
Fonte: www.habr.com