Recientemente, invitamos a Alexei Lesovsky de Data Egret a transmitir Zinc Sale . La conversación resultó ser interesante e informativa, por lo que le ofrezco la transcripción de este tema. Debido al impresionante volumen, fue necesario dividir el texto en pedazos. Si eres demasiado vago para esperar la continuación, puedes escuchar la versión de audio aquí .
Hola a todos, este es el cuadragésimo número del podcast Zinc Prod, y Anton Okolelov, Nikita Vasilchenko y Oleg Gritsak son los anfitriones permanentes con nosotros en el estudio.
Anton : Entonces, hoy tenemos un invitado, Alexey Lesovsky. Lesha, preséntate, quién eres, qué haces, etc.
Alexei : Hola a todos, mi nombre es Alexei Lesovsky, ya que Antokha ya me presentó. Estoy administrando Postgres, soy PostgreSQL DBA (administrador de base de datos), trabajo con el inicio de sesión todos los días, 7 días a la semana, y administro bases de datos de clientes. Tenemos una oficina: es una empresa de consultoría, se dedica a la administración, soporte y soporte. Y personas muy diferentes acuden a nosotros con sus bases de datos, por regla general, son empresas (pequeñas, grandes, pequeñas, todo tipo de diferentes) tienen problemas con la base de datos, analizamos estos problemas y de alguna manera tratamos de solucionarlos. En realidad, resolvemos los problemas de otras personas, otras compañías. Algo asi.
Bueno, en mi tiempo libre me gusta hacer cosas diferentes, caminar por el bosque, hacer snowboard, caminar, beber cerveza
Anton : bebe cerveza ahumada
Nikita : antes del lanzamiento, Lyokha habló sobre la cerveza ahumada
Alexei : sí, cerveza ahumada, hay una deliciosa, recomiendo. Rauchbier Merzen.
Anton : ok, por favor dime, dbshnik, has estado trabajando durante mucho tiempo, varios años. Que tan dificil es Te llaman por la noche y te piden que arregles la base. Te llamé a las cinco de la mañana hace un año o medio.
Alexei : sí, lo era, era un asunto.
Anton : como sobrevives dime
Alexey : escucha, llevo trabajando desde 2014. Hasta 2014, trabajé como administrador de Linux en desarrollo web. El administrador tiene muchas cosas, teníamos virtualización de kvm, había una gran cantidad de Linux, había todo tipo de Ruby-on-rails, nginxs, php, rails ...
Oleg : Docker ya ha estado?
Alexey : Docker acaba de comenzar, no lo hemos introducido en ninguna parte de la producción, pero las tendencias para esto ya han comenzado.
Y había muchos postgres en nuestra oficina. Luego perseguí un rublo largo y decidí que podía trabajar en dos trabajos al mismo tiempo. Y comenzó a trabajar como administrador de forma remota en una oficina de Moscú. Combiné dos trabajos, allí solo las bases de datos fueron administradas por Postgresql consulting. Estaba Max Boguk, Ilya Kosmodemyansky, y como administrador comencé a hacer parte de las tareas relacionadas con el saco. Bueno, es decir Comencé a tomar tranquilamente su pan. Y en algún momento, Max me dice esto: escucha y deja que trabajes con nosotros. Dejará todo su trabajo, trabajos a tiempo parcial, vendrá a nosotros por tiempo completo.
Bueno, acepté, no lo dudé, en principio me ofrecieron un salario comparable, conseguí un trabajo y comencé a trabajar desde casa, y ahora desde 2014, resulta que he estado trabajando durante 5 años, trabajo específicamente con el padre, bueno, a la antigua usanza de todo tipo de temas administrativos, trabajo con ellos por costumbre. Es decir si en nuestra empresa hay un problema con algo que entender desde el lado del administrador, me rechazan, entiendo
Anton : Pero en general, ¿es necesario saber estas cosas de administración? No solo está allí, la base está en el vacío, está girando en alguna parte, necesita configurar el sistema operativo, ¿verdad?
Alexei : sí, sí, eso es exactamente porque generalmente depende en gran medida de los subsistemas del sistema operativo, la memoria virtual y la administración del disco, es decir. es como si él mismo no operara directamente los recursos, como si descargara todo este trabajo al sistema operativo, y él mismo administra la E / S de disco, la administración de la página de memoria, eso es todo, el cambio de proceso y, en consecuencia, si encuentra un cierre de postgres, debe También hay un pequeño truco en el sistema operativo, cómo funciona todo allí y cómo funciona en la interfaz con postgres.
Si, por ejemplo, se compara con Oracle, Oracle tiene, por ejemplo, sus propios subsistemas que funcionan con entrada-salida, es decir, han pasado el sistema operativo, pueden trabajar directamente con el disco, pero en Posgres no es así, necesita saber cómo funciona el sistema operativo con la base de datos.
Oleg : ¿tuviste que soportar postgres en Windows?
Alexei : sí, tuve que hacerlo, tenemos un cliente, están con Windows, servimos a algún tipo de oficina de San Petersburgo, les hicimos una auditoría de la base de datos. Su base estaba en Windows, en general daba miedo, nos conectamos a algún protocolo a través del protocolo del terminal, Escritorio remoto abierto, lanzamos algunas cosas relacionadas con la grabación del rendimiento allí. En resumen, fue difícil, aterrador, cómo ahora se recuerda un sueño terrible. Y ahora los clientes están básicamente sentados en Linux. Prácticamente nadie está en Windows.
Oleg : ¿cuál es el dolor principal en Postgre que todos pueden notar?
Alexey : mucha gente quiere un autoarchivador y un multimaestro. Bueno, multimaster, por supuesto, tal cosa, inalcanzable. Pero todos trabajaron con Galera (con Mysql), y dicen: por qué, también queremos un multimaster en progreso.
Bueno, en el progreso hay tales cosas, pero no en el núcleo progresivo en sí, hay cosas que implementan el tipo de multimaestro, pero aún no se han producido en absoluto. Pero la gente quiere un multimaster. Y la gente también quiere un archivador automático. Pero ahora, gracias a Dios que Patroni ha aparecido, en Patroni puedes hacer un autoarchivador, la gente lo está introduciendo lentamente. Bueno, en general, desde mi punto de vista, Patroni se ha convertido en el estándar de facto. Muchas grandes empresas ya lo están implementando. El mismo Gitlab, recientemente hicieron informes, usan Patroni, están contentos con todo, todos están contentos.
Anton : Escucha, ¿puedes decirnos en pocas palabras qué clientes son para programadores simples? Principalmente escuchamos a los líderes de equipo y programadores.
Nikita : espera, ¿puedo matarte? Y pediré aún más a los no programadores que expliquen qué es un multimaster
Alexei : mira, imagina ahora, Antokha es un programador, escribe aplicaciones y la aplicación necesita almacenar sus datos en algún lugar. Los pone en la base, en la embajada. En algún momento, la base de datos se encuentra en un servidor y luego el servidor una vez, y dejó de funcionar. La fuente de alimentación está quemada y la aplicación necesita continuar trabajando con la base. Y aquí surge la opción de que necesitamos tener algún tipo de copia de la base de datos y continuar trabajando con ella. Y cambie a él, e idealmente, no haga ningún cambio para que nuestra aplicación conozca esta segunda base y continúe escribiendo en ella.
Esto es en realidad un multimaestro, cuando tenemos varios nodos disponibles para leer y escribir, y nuestra aplicación puede trabajar simultáneamente con ellos y escribir datos en cualquiera de estos nodos y leer datos de estos nodos, pero la naturaleza está tan organizada que no se alcanza de manera ideal, y hay pros y contras, hay desventajas, sus propios casos de uso para usar el multimaster. El ejemplo más común es que no puede escribir los mismos datos, en términos relativos, en dos instancias, por ejemplo, trabajar con la misma tabla, escribir en la misma tabla a través de dos servidores, habrá conflictos y deben resolverse, esto es un problema por lo tanto, es necesario escribir si escribimos en una tabla, luego escribimos solo a través de un servidor.
Nikita : y esto está directamente relacionado con el ventilador automático, sí, ¿está conectado?
Alexei : sí, y esto se debe al auto-fildeador, aquí, por así decirlo, uno sigue al otro. Si no podemos permitirnos un multimaster, entonces queremos algún tipo de mecanismo transparente que cambie el nodo de reserva al modo maestro, es decir. tenemos una aplicación, funciona, y tan pronto como la aplicación es eliminada de la base de datos, el desarrollador no quiere cambiar las configuraciones de esta aplicación e indicar la nueva dirección de la base de datos allí, reiniciar la aplicación, especialmente si hay muchas aplicaciones. Quiero algún tipo de mecanismo transparente que funcione en algún lugar bajo el capó, cambie la base de datos, y nuestra aplicación funcionará con la misma dirección y continuará leyendo de esta base de datos. Para hacer esto, ya necesita un archivador automático que cambie de manera transparente el nodo de repuesto al modo asistente, y para esto Patroni solo se usa
Anton : ¿Patroni es un interruptor puro o un tenedor de postgres, algún tipo de complemento?
Alexei : esto, por así decirlo, es un servicio separado, un proceso separado que se ejecuta en un host con una base de datos. Y supervisa el estado del clúster posterior al clúster. Aquí se persiguen dos objetivos: autoajuste y gestión de clústeres. Pero en este caso obtenemos un clúster distribuido, pero tenemos varios nodos en el clúster, un maestro y varias réplicas. En consecuencia, debe monitorear constantemente el estado del clúster, ver constantemente si el maestro está vivo. Si murió repentinamente, debe cambiar al rol de "maestro" de otro servidor. Y para esto se usa, en general, hay dos enfoques, cómo apoyar este grupo de vistas, la vista en el grupo de cómo debería vivir en este momento. Hay una opción cuando cada uno de los nodos del clúster se verifican entre sí. Y puede almacenar este estado afuera, es decir Fuera del cúmulo. Y solo Patroni usa este enfoque, toma y almacena el estado del clúster en el tercer sistema. Esto suele ser algún tipo de DCS (configuración del sistema de almacenamiento distribuido). Puede ser etcd, cónsul, o puede ser kuberenetesovsky etcd. Es decir dependiendo de cuál sea la infraestructura. Bueno, en consecuencia, Patroni simplemente guarda un estado de clúster en este sistema DCS y lo actualiza.
Si de repente uno de los nodos falla repentinamente, se selecciona un nuevo nodo. Si este maestro, por ejemplo, se cae, se selecciona un nuevo maestro y este estado se actualiza nuevamente en DCS. Y aquí a expensas de DCS Patroni apoya la salud del clúster.
Anton : ¿Y si la red parpadea entre Patroni y la base?
Alexei : Mira, hay una base de datos, es algún tipo de servidor o, por ejemplo, en Kubernetes puede ser algún tipo de servidor. Considere un caso simple, digamos que este es un servidor. En el mismo servidor, tenemos una base de datos ejecutándose, y en el mismo servidor ejecutamos el agente Patroni. Este es un proceso liviano, trabajan en el mismo host y se comunican relativamente hablando en localhost. Nuestra red puede parpadear entre el repositorio DCS y el host donde trabajan la base y Patroni.
Puede haber diferentes opciones. Dependiendo de la gravedad de este parpadeo de la red. Sucede que si se trataba de un maestro y resultó estar aislado, los otros nodos descubrirán que el maestro se había ido. Simplemente seleccionarán un nuevo maestro, y verá el viejo maestro que está aislado, y Patroni lo reiniciará en modo de solo lectura. Bueno, para que no haya cerebro dividido. Es malo si nuestra aplicación escribe en dos nodos al mismo tiempo. Luego, los desarrolladores tendrán que rastrillar los datos, y este es un trabajo muy difícil: recopilar estos datos de forma coherente. Por lo tanto, el mandril simplemente reinicia el nodo en solo lectura y eso es todo, y funciona. Tan pronto como se restablezca la red, Patroni podrá llegar a DCS, coordinarán la vista del clúster más allá y llegarán a algún tipo de solución acordada. Lo más probable es que este nodo aislado, que era un viejo maestro, se conecte como una réplica al nuevo maestro ...
Anton Bueno, en la práctica, ¿cómo funciona? ¿Hay algún problema, trampas? Para que Oleg tome e implemente, por ejemplo, Patroni, debe tomar una decisión al respecto.
Oleg Si enseguida
Alexey Bueno, mira, hemos estado usando Patroni con clientes desde el año pasado. Tenemos el primer cliente apareció en mi opinión en noviembre de 2018. Y en ese momento no teníamos una muy buena idea de cómo trabajar con esto, pero durante el año que trabajamos, en principio, todo nos conviene. Aprendimos a cocinarlo. En principio, para recordarlo, en general, realmente no necesita muchos pasos, literalmente dos o tres acciones del lado de postgres, del lado de las configuraciones del usuario, y todo esto funciona bastante bien.
La pieza es confiable. Primero es simple, está escrito en Python, consume poca memoria y funciona en principio de manera confiable. Lo único en la infraestructura debería ser este DCS. Pero, por regla general, es necesario Cónsul o etc. Pero para muchas empresas, esto ya se usa para todo tipo de descubrimiento de servicios diferentes, por lo tanto, como regla, no hay problemas con esto.
Y qué tipo de problemas surgen: el problema más básico que la gente no siente de inmediato es que podemos perder algunos de los datos con el archivador automático
Oleg : debido al retraso de replicación?
Alexei : imagina una situación en la que se produce un archivador automático durante la replicación, el viejo maestro se desconectó, pero aún escribimos parte de los datos en él. Supongamos que hay algún tipo de retraso de replicación, se selecciona un nuevo maestro entre otras réplicas. Se genera un nuevo maestro y si Patroni se configura de tal manera que el nodo caído se incluye automáticamente en el clúster, por ejemplo, el inicio automático de los servicios se activa, luego, cuando el viejo maestro se eleva, ve que ya no es un maestro, está detrás, intentará conectarse al nuevo maestro y convertirse en su señal Y en ese momento ejecuta el comando pg_rewind.
Este comando rebobina el registro de transacciones en el nodo anterior (el antiguo maestro) hasta que pueda conectarse al nuevo maestro, es decir, se sobrescribe el registro de transacciones. En este punto, podemos perder algunos de los datos. En Patroni en sí hay poca protección, hay algunos giros que permiten que las réplicas no participen en las elecciones con un gran retraso. Si, por ejemplo, todas las réplicas tienen un gran retraso, entonces las elecciones simplemente no se iniciarán, y luego la intervención manual del administrador es necesaria para que el administrador entre y comience el archivo automático a mano. O todos esperarán hasta que el viejo maestro se levante. Hasta que su trabajo sea restaurado. Y ya estarán conectados a él y continuarán atrapándolo.
Bueno, es decir, en Patroni hay mecanismos que le permiten no perder datos, pero existe un riesgo, por lo que debe
Anton : ¿qué pasa con la replicación sincrónica?
Alexei : replicación síncrona, ya ves, cuando usamos replicación síncrona, perdemos rendimiento. No todos pueden ir por este trato. Pero si usamos la replicación sincrónica, el riesgo de pérdida de datos se reduce. Pero si usamos varios nodos, digamos más de dos, aún debemos considerar la opción cuando tenemos un accidente tanto en el maestro como en la réplica síncrona. Y todavía tenemos una segunda réplica, y puede resultar que podamos atraparla y perder parte de los datos nuevamente. Son posibles diferentes opciones, deben evaluarse, analizarse y comprenderse si tal comportamiento nos conviene o no.
Anton : escucha, solo dos servidores se caen, es como prever una invasión de extraterrestres
Aleksey : y hay un slammer sobre la anciana
Oleg : ¿recuerdas la misma llamada a Lesha a las cinco de la mañana por última vez, con lo que estaba interesantemente conectado, Anton, y no es que perdimos dos bases de inmediato?
Anton : fue un factor humano. Pues sí, eso pasa.
Alexey : por cierto, no recuerdo el motivo de la llamada
Anton : transferimos dos servidores allí, trabajaron en paralelo, registraron datos, no importa. Y los sistemas podían funcionar en uno, pero uno fue transferido a otro centro de datos, encendido. El segundo fue transportado hasta el momento, y se tocó algún tipo de cableado en el momento de la instalación, y el viejo también se cortó: mezclaron algo. En general, los dos servidores cayeron, comenzamos a subir y, dado que estaban rígidamente configurados para grabar, tenían puntos de control muy raros o algo así. Comenzó durante mucho tiempo, no entendimos lo que estaba sucediendo
Oleg : cien conciertos wal-logs
Anton : no entendimos lo que estaba sucediendo, por qué no comenzó, y como resultado tuve que hacer una llamada. Bueno, en realidad no había nada especial que hacer ...
Alexei : bueno, es lo único que probablemente hemos conectado, hemos visto que todo está en orden
Oleg : confirmó la muerte del paciente
Anton : de hecho, solo tenías que esperar, en general.
Alexey Sí, bueno, este es un problema conocido. Con algunas configuraciones, los puntos de control son largos. Hay tal problema.
Pero, en general, si recuerda esta llamada nocturna, en la práctica rara vez llamamos por la noche, tenemos una configuración de automatización especial: de servicio, todo está como debería, seleccionado de acuerdo con un horario especial. Entonces, si recuerdas, bueno, tal vez una vez cada seis meses alguien llame
Oleg : todo de nuestra empresa es probable
Alexey : no, diferente
Anton : Oleg, llama más seguido
Oleg : haremos un cambio hoy, probablemente llamaré
Alexey : tenemos chicos, su hora de la tarde se está cerrando, simplemente trabajarán
Anton : escucha, Lech, dijiste que Patroni tiene algunos análogos. ¿Cómo difieren, cuáles son
Alexey : básicamente hay dos opciones, hay una respuesta, esto apareció hace mucho tiempo, hace unos 10 años. Implementa un mecanismo cuando los nodos de un clúster posterior a la gracia se comprueban entre sí, quién está vivo, quién no está vivo. Pero en mi opinión esto no es muy, realmente no me gusta este esquema de trabajo.
Y no hay un archivador automático fuera de la caja, repmgr fue afilado originalmente específicamente para administrar el clúster y para el cambio manual, para el cambio. Y si desea archivar automáticamente directamente, entonces necesita instalar el demo repmgrd por separado, y resulta que el archivo automático se inicia aquí. La cosa es conveniente, buena, pero sí, no tenemos un autoarchivador listo para usar. Necesitas ponerlo por separado. En general, la cosa es buena, conveniente, en el sentido de que es bien configurable, es conveniente mantener los clústeres basados en clústeres. Ella es muy flexible, personalizable. Las réplicas se pueden verter de varias maneras. Desde copias de seguridad, desde réplicas para verter otras, desde el maestro. En resumen, una cosa tan flexible, porque 10 años. Y se introdujeron muchas características diferentes, es muy bueno.
Y otra opción es Stolon. Apareció casi al mismo tiempo que Patroni, un poco más tarde. Está escrito en Go.
Pero tiene una arquitectura más ramificada. Si abre el sitio web del proyecto, habrá imágenes, y Stolon en sí consta de varios componentes. Tiene nodos guardianes que trabajan con bases de datos que generan Postges. Luego están los llamados nodos Centinela. Supervisan el estado del clúster, verifican su disponibilidad, verifican que los nodos estén vivos o no vivos. Administran el estado del clúster y lo reconfiguran si sucede algo.
Y hay los llamados nodos proxy, todo el tráfico los atraviesa. La aplicación cliente funciona con proxies. -, - , . Es decir . , , Stolon DCS, consul, etcd. - .
, - , bare metal , , - , . . ( -) , , .
, . . , . , . oltp- . Stolon , .
, 6 8, . , , . , — wal_keep_segments — - , , , . , - . , . . Es decir , . , , . , — . .
: , , - Citus? , .
: Citus — . Citus , CitusDB, -. , , ,
: ?
: , , . . , pg autofailover. , . , , . , , . , , . , , . Es decir .
: Citus. , , . — , ...
: , ,
: , , , , ,
: , , . , , , . "in the wild" . , .
La continuación del descifrado del problema se publicará en Habr en un futuro próximo, pero por ahora suscríbase al podcast Zinc Prod , ¡hay muchas cosas interesantes por delante!