Le sugiero que lea la transcripción del informe de principios de 2020 de Georgy Rylov “WAL-G: nuevas oportunidades y expansión de la comunidad”
Los mantenedores de código abierto enfrentan muchos desafíos a medida que crecen. ¿Cómo escribir más y más funciones requeridas, solucionar más y más problemas y lograr ver más y más solicitudes de extracción? Usando WAL-G (herramienta de respaldo para PostgreSQL) como ejemplo, les contaré cómo resolvimos estos problemas lanzando un curso sobre desarrollo de código abierto en la universidad, qué logramos y hacia dónde nos moveremos a continuación.
¡Hola de nuevo a todos! Soy desarrollador de Yandex de Ekaterimburgo. Y hoy hablaré de WAL-G.
El título del informe no decía que se tratara de copias de seguridad. ¿Alguien sabe qué es WAL-G? ¿O todos lo saben? Levanten la mano si no lo saben. Mierda, llegaste al informe y no sabes de qué se trata.
Déjame decirte lo que pasará hoy. Sucede que nuestro equipo lleva bastante tiempo haciendo copias de seguridad. Y este es otro informe de una serie en la que hablamos sobre cómo almacenamos datos de forma segura, cómoda y eficiente.
En series anteriores hubo muchos reportajes de Andrei Borodin y Vladimir Leskov. Éramos muchos. Y llevamos muchos años hablando de WAL-G.
clck.ru/F8ioz—
clck.ru/Ln8Qw—
Este informe será un poco diferente de los demás en que trató más sobre la parte técnica, pero aquí hablaré sobre cómo encontramos problemas asociados con el crecimiento de la comunidad. Y cómo se nos ocurrió una pequeña idea que nos ayuda a afrontar esto.
Hace unos años, WAL-G era un proyecto bastante pequeño que obtuvimos de Citus Data. Y simplemente lo tomamos. Y fue desarrollado por una sola persona.
Y solo WAL-G no tenía:
- Copia de seguridad desde una réplica.
- No hubo copias de seguridad incrementales.
- No hubo copias de seguridad de WAL-Delta.
- Y todavía faltaba mucho.
En estos años, WAL-G ha crecido mucho.
Y para 2020, todo lo anterior ya ha aparecido. Y a esto se le sumó lo que ahora tenemos:
- Más de 1 estrellas en GitHub.
- 150 tenedores.
- Alrededor de 15 relaciones públicas abiertas.
- Y muchos más contribuyentes.
- Y temas abiertos todo el tiempo. Y esto a pesar de que literalmente vamos allí todos los días y hacemos algo al respecto.
Y llegamos a la conclusión de que este proyecto requiere más atención, incluso cuando nosotros mismos no necesitamos implementar nada para nuestro servicio de Bases de datos administradas en Yandex.
Y en algún momento del otoño de 2018, se nos ocurrió una idea. Por lo general, el equipo tiene varias formas de desarrollar algunas funciones o corregir errores si no tienes suficientes manos. Por ejemplo, puedes contratar a otro desarrollador y pagarle dinero. O puedes contratar a un pasante por un tiempo y también pagarle un salario. Pero todavía hay un grupo bastante grande de personas, algunas de las cuales ya saben realmente cómo escribir código. Simplemente no siempre se sabe qué calidad es el código.
Lo pensamos y decidimos intentar atraer estudiantes. Pero los estudiantes no participarán en todo con nosotros. Sólo harán una parte del trabajo. Y, por ejemplo, escribirán pruebas, corregirán errores e implementarán funciones que no afecten la funcionalidad principal. La funcionalidad principal es crear copias de seguridad y restaurarlas. Si cometemos un error al crear una copia de seguridad, experimentaremos una pérdida de datos. Y nadie quiere esto, por supuesto. Todo el mundo quiere que todo sea muy seguro. Por lo tanto, por supuesto, no queremos permitir que el código en el que confiamos sea menos que el nuestro. Es decir, cualquier código no crítico es el que nos gustaría recibir de nuestros trabajadores adicionales.
¿En qué condiciones se aceptan las relaciones públicas estudiantiles?
- Deben cubrir su código con pruebas. Todo debería ocurrir en CI.
- Y también repasamos 2 reseñas. Uno de Andrey Borodin y otro mío.
- Y además, para comprobar que esto no romperá nada en nuestro servicio, subo por separado el ensamblado con este compromiso. Y comprobamos en pruebas extremo a extremo que no falla nada.
Curso especial sobre Código Abierto
Un poco sobre por qué es necesario y por qué, me parece, es una buena idea.
Para nosotros, el beneficio es obvio:
- Conseguimos manos extra.
- Y estamos buscando candidatos para el equipo entre estudiantes inteligentes que escriban código inteligente.
¿Cuál es el beneficio para los estudiantes?
Pueden ser menos obvios, porque los estudiantes, como mínimo, no reciben dinero por el código que escriben, sino que sólo reciben calificaciones por sus registros estudiantiles.
Les pregunté sobre esto. Y en sus palabras:
- Experiencia del colaborador en Open Source.
- Consigue una línea en tu CV.
- Ponte a prueba y pasa una entrevista en Yandex.
- Conviértase en miembro de GSoC.
- +1 curso especial para aquellos que quieran escribir código.
No hablaré de cómo se estructuró el curso. Sólo diré que WAL-G fue el proyecto principal. También incluimos proyectos como Odyssey, PostgreSQL y ClickHouse en este curso.
Y no solo dieron problemas en este curso, sino que también entregaron diplomas y trabajos de curso.
¿Qué pasa con el beneficio para los usuarios?
Ahora pasemos a la parte que más te interesa. ¿De qué te sirve esto? El caso es que los estudiantes solucionaron muchos errores. Y realizamos las funciones solicitadas que usted nos pidió que hiciéramos.
Y déjame contarte las cosas que has deseado durante mucho tiempo y que se han realizado.
Soporte de espacios de tabla. Probablemente se esperaban espacios de tabla en WAL-G desde el lanzamiento de WAL-G, porque WAL-G es el sucesor de otra herramienta de respaldo WAL-E, donde se admitían copias de seguridad de bases de datos con espacios de tabla.
Permítanme recordarles brevemente qué es y por qué es necesario. Normalmente, todos sus datos de Postgres ocupan un directorio en el sistema de archivos, llamado base. Y este directorio ya contiene todos los archivos y subdirectorios requeridos por Postgres.
Los espacios de tabla son directorios que contienen datos de Postgres, pero no están ubicados fuera del directorio base. La diapositiva muestra que los tablepacs están ubicados fuera del directorio base.
¿Cómo se ve esto para el propio Postgres? Hay un subdirectorio separado pg_tblspc en el directorio base. Y contiene enlaces simbólicos a directorios que en realidad contienen datos de Postgres fuera del directorio base.
Cuando use todo esto, estos comandos pueden verse así. Es decir, crea una tabla en algún espacio de tabla específico y ve dónde está ahora. Estas son las dos últimas líneas, los dos últimos comandos llamados. Y ahí queda claro que hay algún camino. Pero en realidad, éste no es el verdadero camino. Esta es la ruta prefijada desde el directorio base hasta el espacio de tabla. Y desde allí se combina con un enlace simbólico que conduce a sus datos reales.
No usamos todo esto en nuestro equipo, pero fue utilizado por muchos otros usuarios de WAL-E que nos escribieron que querían pasar a WAL-G, pero esto los detenía. Esto ahora es compatible.
Otra característica que nos trajo nuestro curso especial es la puesta al día. Las personas que probablemente han trabajado más con Oracle que con Postgres saben acerca de la recuperación.
Brevemente sobre lo que es. La topología del clúster en nuestro servicio normalmente puede verse así. Tenemos un maestro. Hay una réplica que transmite el registro de escritura anticipada. Y la réplica le dice al maestro en qué LSN se encuentra actualmente. Y en algún lugar paralelo a esto, se puede archivar el registro. Y además de archivar el registro, también se envían copias de seguridad a la nube. Y se envían copias de seguridad delta.
¿Cual podría ser el problema? Cuando tiene una base de datos bastante grande, puede resultar que su réplica comience a quedar muy por detrás del maestro. Y ella se queda tan atrás que nunca podrá alcanzarlo. Por lo general, este problema debe resolverse de alguna manera.
Y la forma más sencilla es eliminar la réplica y volver a cargarla, porque nunca se recuperará y es necesario solucionar el problema. Pero esto es bastante tiempo, porque restaurar una copia de seguridad completa de una base de datos de 10 TB es muchísimo tiempo. Y queremos hacer todo esto lo más rápido posible si surgen problemas de este tipo. Y para eso es exactamente la recuperación.
Catchup le permite utilizar copias de seguridad delta, que se almacenan en la nube de esta manera. Usted dice en qué LSN se encuentra actualmente la réplica retrasada y lo especifica en el comando catchup para crear una copia de seguridad delta entre ese LSN y el LSN en el que se encuentra actualmente su clúster. Y luego restaura esta copia de seguridad en la réplica que estaba rezagada.
Otras bases
Los estudiantes también nos trajeron muchas funciones a la vez. Dado que en Yandex no solo cocinamos Postgres, también tenemos MySQL, MongoDB, Redis, ClickHouse, en algún momento necesitábamos poder hacer copias de seguridad con recuperación de un momento determinado para MySQL, y para que hubiera una oportunidad de cargar a la nube.
Y queríamos hacerlo de alguna manera similar a lo que hace WAL-G. Y decidimos experimentar y ver cómo quedaría todo.
Y al principio, sin compartir esta lógica de ninguna manera, escribieron el código en el fork. Vieron que tenemos algún tipo de modelo funcional y que puede volar. Entonces pensamos que nuestra comunidad principal son los postgresistas, usan WAL-G. Y por eso necesitamos de alguna manera separar estas partes. Es decir, cuando editamos código para Postgres, no rompemos MySQL; cuando editamos MySQL, no rompemos Postgres.
La primera idea sobre cómo separar esto fue la idea de utilizar el mismo enfoque que se utiliza en las extensiones de PostgreSQL. Y, de hecho, para hacer una copia de seguridad de MySQL había que instalar algún tipo de biblioteca dinámica.
Pero aquí la asimetría de este enfoque es inmediatamente visible. Cuando haces una copia de seguridad de Postgres, le colocas una copia de seguridad normal para Postgres y todo está bien. Y para MySQL resulta que instalas una copia de seguridad para Postgres y también instalas una biblioteca dinámica para MySQL. Suena un poco extraño. Nosotros también pensamos lo mismo y decidimos que esa no era la solución que necesitábamos.
Varias compilaciones para Postgres, MySQL, MongoDB, Redis
Pero nos parece que esto nos permitió tomar la decisión correcta: asignar diferentes asambleas para diferentes bases. Esto hizo posible aislar la lógica vinculada a las copias de seguridad de varias bases de datos que accederán a la API común que implementa WAL-G.
Esta es la parte que escribimos nosotros mismos, antes de darles los problemas a los estudiantes. Es decir, esta es exactamente la parte en la que podrían hacer algo mal, así que decidimos que sería mejor hacer algo como esto y todo estará bien.
Después de eso dimos problemas. Fueron desmantelados inmediatamente. Se requirió que los estudiantes apoyaran tres bases.
Este es MySQL, al que hemos estado respaldando usando WAL-G de esta manera durante más de un año.
Y ahora MongoDB se acerca a producción, donde lo están terminando con un archivo. De hecho, escribimos el marco para todo esto. Luego los estudiantes escribieron algunas cosas viables. Y luego los llevamos a un estado que podamos aceptar en producción.
Estos problemas no parecían indicar que los estudiantes necesitaran escribir herramientas de respaldo completas para cada una de estas bases de datos. No tuvimos tal problema. Nuestro problema era que queríamos una recuperación en un momento dado y queríamos realizar una copia de seguridad en la nube. Y pidieron a los estudiantes que escribieran algún código que resolviera esto. Los estudiantes utilizaron herramientas de respaldo ya existentes, que de alguna manera realizan respaldos, y luego lo unieron todo con WAL-G, que lo reenvió todo a la nube. Y a esto también le sumaron la recuperación puntual.
¿Qué más trajeron los estudiantes? Trajeron soporte de cifrado Libsodium a WAL-G.
También contamos con políticas de almacenamiento de respaldo. Ahora las copias de seguridad se pueden marcar como permanentes. Y de alguna manera es más conveniente para su servicio automatizar el proceso de almacenamiento.
¿Cuál fue el resultado de este experimento?
Inicialmente se inscribieron más de 100 personas al curso. Al principio no dije que la universidad de Ekaterimburgo es la Universidad Federal de los Urales. Allí anunciamos todo. 100 personas registradas. En realidad, mucha menos gente empezó a hacer algo, unas 30 personas.
Aún menos personas completaron el curso, porque fue necesario escribir pruebas para los códigos que ya existen. Y también corregir algún error o crear alguna característica. Y algunos estudiantes aún cerraron el curso.
Actualmente, durante este curso, los estudiantes solucionaron alrededor de 14 problemas y crearon 10 funciones de varios tamaños. Y me parece que este es un reemplazo completo de uno o dos desarrolladores.
Entre otras cosas, emitimos diplomas y trabajos de curso. Y 12 recibieron diplomas. 6 de ellos ya se han defendido en el “5”. Los que se quedaron aún no tenían protección, pero creo que para ellos también todo estará bien.
Planes para el futuro
¿Qué planes tenemos para el futuro?
Al menos aquellas solicitudes de funciones que ya hemos escuchado de los usuarios y queremos hacer. Este:
- Monitorear la exactitud del seguimiento de la línea de tiempo en el archivo de respaldo del clúster HA. Puedes hacer esto con WAL-G. Y creo que tendremos estudiantes que abordarán este asunto.
- Ya tenemos una persona responsable de transferir copias de seguridad y WAL entre nubes.
- Y recientemente publicamos una idea de que podemos acelerar WAL-G aún más descomprimiendo copias de seguridad incrementales sin reescribir páginas y optimizando los archivos que enviamos allí.
Puedes compartirlos aquí
¿Para qué fue este informe? Además, ahora, además de las 4 personas que apoyan este proyecto, tenemos manos adicionales, que son bastantes. Especialmente si les escribes en un mensaje personal. Y si realiza una copia de seguridad de sus datos y lo hace utilizando WAL-G o desea pasar a WAL-G, entonces podemos satisfacer sus deseos con bastante facilidad.
Este es un código QR y un enlace. Puedes revisarlos y escribir todos tus deseos. Por ejemplo, no estamos solucionando algún error. O realmente desea alguna función, pero por alguna razón aún no está en ninguna copia de seguridad, incluida la nuestra. Asegúrate de escribir sobre esto.
preguntas
¡Hola! ¡Gracias por el informe! Pregunta sobre WAL-G, pero no sobre Postgres. WAL-G realiza una copia de seguridad de MySQL y solicita una copia de seguridad adicional. Si tomamos instalaciones modernas en CentOS y si instala yum MySQL, se instalará MariDB. A partir de la versión 10.3 no se admiten copias de seguridad adicionales, pero sí se admiten copias de seguridad de MariDB. ¿Cómo te va con esto?
Por el momento no hemos intentado hacer una copia de seguridad de MariDB. Hemos recibido solicitudes de soporte de FoundationDB, pero en general, si existe tal solicitud, podemos encontrar personas que lo hagan. No es tan largo ni tan difícil como creo.
Buenas tardes ¡Gracias por el informe! Pregunta sobre posibles nuevas funciones. ¿Está listo para hacer que WAL-G funcione con cintas para poder realizar copias de seguridad en cintas?
¿Aparentemente significa hacer copia de seguridad en almacenamiento en cinta?
Sí.
Está Andrei Borodin, que puede responder a esta pregunta mejor que yo.
(Andrey) ¡Sí, gracias por la pregunta! Recibimos una solicitud para transferir una copia de seguridad a cinta desde el almacenamiento en la nube. y por esto transferencia entre nubes. Porque la transferencia de nube a nube es una versión generalizada de la transferencia de cinta. Además, contamos con una arquitectura extensible en cuanto a Storages. Por cierto, muchos Storoges fueron escritos por estudiantes. Y si escribe Almacenamiento para cinta, entonces, por supuesto, será compatible. Estamos listos para considerar las solicitudes de extracción. Allí necesitas escribir un archivo, leer un archivo. Si haces estas cosas en Go, normalmente terminarás con 50 líneas de código. Y luego la cinta será compatible con WAL-G.
¡Gracias por el informe! Interesante proceso de desarrollo. La copia de seguridad es una funcionalidad importante que debería estar bien cubierta por las pruebas. Cuando implementó la funcionalidad para nuevas bases de datos, ¿los estudiantes también escribieron las pruebas o usted mismo las escribió y luego les dio la implementación a los estudiantes?
Los estudiantes también escribieron exámenes. Pero los estudiantes escribieron más para funciones como nuevas bases de datos. Escribieron pruebas de integración. Y escribieron pruebas unitarias. Si la integración pasa, es decir, de momento, este es un script que ejecutas manualmente o tienes cron haciéndolo, por ejemplo. Es decir, el guión ahí es muy claro.
Los estudiantes no tienen mucha experiencia. ¿La revisión lleva mucho tiempo?
Sí, las revisiones llevan bastante tiempo. Eso es, por lo general, cuando varios confirmadores vienen a la vez y dicen que hice esto, hice aquello, entonces debes pensar y reservar aproximadamente medio día para descubrir qué escribieron allí. Porque el código debe leerse con atención. No tuvieron una entrevista. No los conocemos muy bien, por lo que lleva mucho tiempo.
¡Gracias por el informe! Anteriormente, Andrey Borodin afirmó que archive_command en WAL-G debería llamarse directamente. Pero en el caso de algún tipo de cartucho de grupo, necesitamos lógica adicional para determinar el nodo desde el cual enviar los ejes. ¿Cómo resuelves este problema tú mismo?
¿Cuál es tu problema aquí? ¿Digamos que tienes una réplica síncrona con la que estás haciendo una copia de seguridad? ¿O que?
(Andrey) El hecho es que, de hecho, WAL-G está diseñado para usarse sin scripts de shell. Si falta algo, agreguemos la lógica que debería estar dentro de WAL-G. En cuanto a de dónde debe provenir el archivado, creemos que el archivado debe realizarse desde el maestro actual en el clúster. Archivar desde una réplica es una mala idea. Hay varios escenarios posibles con problemas. En particular, problemas con el archivo de cronogramas y cualquier información adicional. ¡Gracias por la pregunta!
(Aclaración: nos deshicimos de los scripts de shell )
¡Buenas noches! ¡Gracias por el informe! Estoy interesado en la función de actualización de la que hablaste. Nos enfrentamos a una situación en la que una réplica estaba detrás y no podía alcanzarnos. Y no encontré una descripción de esta característica en los documentos WAL-G.
Catchup apareció literalmente el 20 de enero de 2020. Es posible que la documentación necesite algo más de trabajo. Lo escribimos nosotros mismos y no lo escribimos muy bien. Y quizás deberíamos empezar a exigir a los estudiantes que lo escriban.
¿Ya está liberado?
La solicitud de extracción ya está muerta, es decir, la verifiqué. Probé esto en un grupo de prueba. Hasta ahora no hemos tenido una situación en la que pudiéramos probar esto en un ejemplo de combate.
¿Cuándo esperar?
No sé. Espera un mes, lo comprobaremos con seguridad.
Fuente: habr.com