En algún momento en un futuro lejano, la eliminación automática de datos innecesarios será una de las tareas importantes del DBMS [1]. Mientras tanto, nosotros mismos debemos encargarnos de eliminar o mover datos innecesarios a sistemas de almacenamiento menos costosos. Supongamos que decide eliminar algunos millones de filas. Una tarea bastante sencilla, especialmente si se conoce la condición y existe un índice adecuado. "ELIMINAR DE tabla1 DONDE col1 =: valor": ¿qué podría ser más simple, verdad?
Vídeo:
-
He estado en el comité del programa Highload desde el primer año, es decir, desde 2007.
-
Y he estado con Postgres desde 2005. Lo usé en muchos proyectos.
-
Grupo con RuPostges también desde 2007.
-
Hemos crecido a más de 2100 participantes en Meetup. Es la segunda del mundo después de Nueva York, superada por mucho tiempo por San Francisco.
-
He vivido en California durante varios años. Trato más con empresas estadounidenses, incluidas las grandes. Son usuarios activos de Postgres. Y hay todo tipo de cosas interesantes.
es mi empresa Estamos en el negocio de la automatización de tareas que eliminan las ralentizaciones del desarrollo.
Si está haciendo algo, a veces hay algún tipo de enchufe alrededor de Postgres. Digamos que debe esperar a que el administrador configure un banco de pruebas para usted, o debe esperar a que el DBA le responda. Y encontramos tales cuellos de botella en el proceso de desarrollo, prueba y administración y tratamos de eliminarlos con la ayuda de la automatización y nuevos enfoques.
Hace poco estuve en VLDB en Los Ángeles. Esta es la mayor conferencia sobre bases de datos. Y hubo un informe que en el futuro DBMS no solo almacenará, sino que también eliminará datos automáticamente. Este es un tema nuevo.
Cada vez hay más datos en el mundo de los zettabytes, eso es 1 de petabytes. Y ahora ya se estima que tenemos más de 000 zettabytes de datos almacenados en el mundo. Y hay más y más de ellos.
¿Y qué hacer con eso? Obviamente hay que quitarlo. Aquí hay un enlace a este interesante informe. Pero hasta ahora esto no se ha implementado en el DBMS.
Aquellos que pueden contar dinero quieren dos cosas. Quieren que eliminemos, así que técnicamente deberíamos poder hacerlo.
Lo que contaré a continuación es una situación abstracta que incluye un montón de situaciones reales, es decir, una especie de compilación de lo que realmente me sucedió a mí y a las bases de datos circundantes muchas veces, muchos años. Los rastrillos están en todas partes y todos los pisan todo el tiempo.
Digamos que tenemos una base o varias bases que están creciendo. Y algunos registros son obviamente basura. Por ejemplo, el usuario comenzó a hacer algo allí, pero no lo terminó. Y después de un tiempo sabemos que este inacabado ya no se puede guardar. Es decir, nos gustaría limpiar algunas cosas basura para ahorrar espacio, mejorar el rendimiento, etc.
En general, la tarea es automatizar la eliminación de cosas específicas, líneas específicas en alguna tabla.
Y tenemos una solicitud de este tipo, de la que hablaremos hoy, es decir, sobre la eliminación de basura.
Le pedimos a un desarrollador experimentado que lo hiciera. Tomó esta solicitud, la comprobó por sí mismo: todo funciona. Probado en la puesta en escena: todo está bien. Lanzado - todo funciona. Una vez al día lo ejecutamos, todo está bien.
La base de datos crece y crece. Daily DELETE comienza a funcionar un poco más lentamente.
Entonces entendemos que ahora tenemos una empresa de marketing y el tráfico será varias veces mayor, por lo que decidimos pausar temporalmente las cosas innecesarias. Y olvida volver.
Unos meses después se acordaron. Y ese desarrollador renunció o está ocupado con otra cosa, instruyó a otro para que lo devuelva.
Revisó el desarrollo, la puesta en escena: todo está bien. Naturalmente, aún necesita limpiar lo que se ha acumulado. Revisó que todo funciona.
¿Qué pasa después? Entonces todo se derrumba para nosotros. Cae para que en algún momento todo se derrumbe. Todos están en estado de shock, nadie entiende lo que está pasando. Y luego resulta que el asunto estaba en este DELETE.
¿Algo salió mal? Aquí hay una lista de lo que podría haber salido mal. ¿Cuál de estos es el más importante?
-
Por ejemplo, no hubo revisión, es decir, el experto DBA no lo miró. Inmediatamente encontraría el problema con un ojo experimentado y, además, tiene acceso a prod, donde se han acumulado varios millones de líneas.
-
Tal vez comprobaron algo mal.
-
Tal vez el hardware esté desactualizado y necesite actualizar esta base.
-
O algo anda mal con la propia base de datos y necesitamos pasar de Postgres a MySQL.
-
O tal vez hay algo mal con la operación.
-
¿Quizás hay algunos errores en la organización del trabajo y necesitas despedir a alguien y contratar a las mejores personas?
No hubo verificación de DBA. Si hubiera un DBA, vería estos varios millones de líneas e incluso sin ningún experimento diría: "No hacen eso". Supongamos que este código estuviera en GitLab, GitHub y hubiera un proceso de revisión de código y no fuera tal que sin la aprobación del DBA esta operación se llevaría a cabo en prod, entonces obviamente el DBA diría: “Esto no se puede hacer. ”
Y diría que tendrá problemas con el disco IO y todos los procesos se volverán locos, puede haber bloqueos, y también bloqueará el vacío automático durante un montón de minutos, por lo que esto no es bueno.
El segundo error: se registraron en el lugar equivocado. Vimos después del hecho de que se acumularon muchos datos basura en la producción, pero el desarrollador no tenía datos acumulados en esta base de datos, y nadie creó esta basura durante la puesta en escena. En consecuencia, hubo 1 líneas que funcionaron rápidamente.
Entendemos que nuestras pruebas son débiles, es decir, el proceso que se construye no detecta problemas. No se realizó un experimento DB adecuado.
Un experimento ideal se lleva a cabo preferiblemente en el mismo equipo. No siempre es posible hacer esto en el mismo equipo, pero es muy importante que sea una copia de tamaño completo de la base de datos. Esto es lo que he estado predicando durante varios años. Y hace un año hablé de esto, puedes verlo todo en YouTube.
¿Quizás nuestro equipo es malo? Si miras, entonces la latencia saltó. Hemos visto que la utilización es del 100%. Por supuesto, si se tratara de unidades NVMe modernas, probablemente sería mucho más fácil para nosotros. Y tal vez no nos acostaríamos.
Si tiene nubes, la actualización se realiza fácilmente allí. Criado nuevas réplicas en el nuevo hardware. pasar a otra cosa. Y todo está bien. Muy fácil.
¿Es posible tocar de alguna manera los discos más pequeños? Y aquí, solo con la ayuda de DBA, nos sumergimos en un tema determinado llamado ajuste de punto de control. Resulta que no teníamos ajuste de punto de control.
¿Qué es el punto de control? Está en cualquier DBMS. Cuando tiene datos en la memoria que cambian, no se escriben inmediatamente en el disco. La información de que los datos han cambiado se escribe primero en el registro de escritura anticipada. Y en algún momento, el DBMS decide que es hora de volcar páginas reales en el disco, de modo que si tenemos una falla, podamos hacer menos REDO. Es como un juguete. Si nos matan, comenzaremos el juego desde el último punto de control. Y todos los DBMS lo implementan.
La configuración en Postgres se está quedando atrás. Están diseñados para volúmenes de datos y transacciones de 10 a 15 años. Y el punto de control no es una excepción.
Aquí está la información de nuestro informe de verificación de Postgres, es decir, verificación de estado automática. Y aquí hay una base de datos de varios terabytes. Y se puede ver bien que los puntos de control forzados en casi el 90% de los casos.
¿Qué significa? Hay dos configuraciones allí. El punto de control puede llegar por tiempo de espera, por ejemplo, en 10 minutos. O puede venir cuando se han llenado bastantes datos.
Y por defecto, max_wal_saze se establece en 1 gigabyte. De hecho, esto realmente sucede en Postgres después de 300-400 megabytes. Ha cambiado tantos datos y su punto de control sucede.
Y si nadie lo ajustó, y el servicio creció, y la empresa gana mucho dinero, tiene muchas transacciones, entonces el punto de control llega una vez por minuto, a veces cada 30 segundos y, a veces, incluso se superpone. Esto es bastante malo.
Y debemos asegurarnos de que ocurra con menos frecuencia. Es decir, podemos aumentar max_wal_size. Y vendrá con menos frecuencia.
Pero hemos desarrollado toda una metodología de cómo hacerlo más correctamente, es decir, cómo tomar una decisión sobre la elección de la configuración, claramente basada en datos específicos.
En consecuencia, estamos haciendo dos series de experimentos sobre bases de datos.
La primera serie: cambiamos max_wal_size. Y estamos haciendo una operación masiva. Primero, lo hacemos con la configuración predeterminada de 1 gigabyte. Y hacemos un DELETE masivo de muchos millones de líneas.
Puedes ver lo difícil que es para nosotros. Vemos que el disco IO es muy malo. Miramos cuántos WAL hemos generado, porque esto es muy importante. Veamos cuántas veces pasó el punto de control. Y vemos que no es bueno.
A continuación, aumentamos max_wal_size. Repetimos. Aumentamos, repetimos. Y tantas veces. En principio, 10 puntos es bueno, donde 1, 2, 4, 8 gigabytes. Y nos fijamos en el comportamiento de un sistema particular. Está claro que aquí el equipo debe ser como en prod. Debe tener los mismos discos, la misma cantidad de memoria y la misma configuración de Postgres.
Y de esta manera intercambiaremos nuestro sistema, y sabremos cómo se comportará el DBMS en caso de un DELETE masivo incorrecto, cómo será el punto de control.
Los puntos de control en ruso son puntos de control.
Ejemplo: ELIMINAR varios millones de filas por índice, las filas están "dispersas" en las páginas.
Aquí hay un ejemplo. Esta es una base. Y con la configuración predeterminada de 1 gigabyte para max_wal_size, está muy claro que nuestros discos van a la estantería para grabar. Este cuadro es un síntoma típico de un paciente muy enfermo, es decir, se sentía realmente mal. Y hubo una sola operación, solo hubo un DELETE de varios millones de líneas.
Si tal operación está permitida en prod, simplemente nos acostaremos, porque está claro que un DELETE nos mata en el estante.
Además, donde 16 gigabytes, está claro que los dientes ya se han ido. Los dientes ya están mejor, es decir, estamos tocando el techo, pero no tan mal. Había algo de libertad allí. A la derecha está el registro. Y el número de operaciones - el segundo gráfico. Y está claro que ya estamos respirando un poco más tranquilos cuando llega a los 16 gigas.
Y donde 64 gigabytes se puede ver que se ha vuelto completamente mejor. Ya los dientes están pronunciados, hay más oportunidades de sobrevivir a otras operaciones y hacer algo con el disco.
¿Por qué es eso?
Me sumergiré un poco en los detalles, pero este tema, cómo realizar el ajuste del punto de control, puede resultar en un informe completo, por lo que no cargaré mucho, pero describiré un poco las dificultades que existen.
Si el punto de control ocurre con demasiada frecuencia y actualizamos nuestras líneas no secuencialmente, sino que buscamos por índice, lo cual es bueno, porque no eliminamos toda la tabla, entonces puede suceder que primero toquemos la primera página, luego la milésima, y luego volvió a la primera. Y si entre estas visitas a la primera página, el punto de control ya lo guardó en el disco, entonces lo guardará nuevamente, porque lo ensuciamos por segunda vez.
Y forzaremos el punto de control para guardarlo muchas veces. ¿Cómo habría operaciones redundantes para él?
Pero eso no es todo. Las páginas tienen 8 kilobytes en Postgres y 4 kilobytes en Linux. Y hay una configuración full_page_writes. Está habilitado por defecto. Y esto es correcto, porque si lo apagamos, existe el peligro de que solo se guarde la mitad de la página si falla.
El comportamiento de escribir en el WAL del registro de reenvío es tal que cuando tenemos un punto de control y cambiamos la página por primera vez, toda la página, es decir, los 8 kilobytes, ingresan en el registro de reenvío, aunque solo cambiamos el línea, que pesa 100 bytes. Y tenemos que escribir toda la página.
En cambios posteriores, solo habrá una tupla específica, pero por primera vez escribimos todo.
Y, en consecuencia, si el punto de control volvió a ocurrir, entonces tenemos que comenzar todo desde cero nuevamente y empujar toda la página. Con puntos de control frecuentes, cuando caminamos por las mismas páginas, full_page_writes = on será más de lo que podría ser, es decir, generaremos más WAL. Se envía más a las réplicas, al archivo, al disco.
Y, en consecuencia, tenemos dos despidos.
Si aumentamos max_wal_size, resulta que lo hacemos más fácil tanto para el punto de control como para el escritor de wal. Y eso es genial.
Pongamos un terabyte y vivamos con él. ¿Qué tiene de malo? Esto es malo, porque en caso de falla, subiremos durante horas, porque el punto de control fue hace mucho tiempo y ya ha cambiado mucho. Y tenemos que hacer todo esto REDO. Y así hacemos la segunda serie de experimentos.
Hacemos una operación y vemos cuando el punto de control está a punto de completarse, matamos -9 Postgres a propósito.
Y después de eso, lo reiniciamos y vemos cuánto tiempo se elevará en este equipo, es decir, cuánto se REHARÁ en esta mala situación.
Dos veces notaré que la situación es mala. Primero, nos estrellamos justo antes de que terminara el punto de control, así que tenemos mucho que perder. Y en segundo lugar, tuvimos una operación masiva. Y si los puntos de control estuvieran en tiempo de espera, lo más probable es que se generara menos WAL desde el último punto de control. Es decir, es un doble perdedor.
Medimos tal situación para diferentes tamaños de max_wal_size y entendemos que si max_wal_size es de 64 gigabytes, en el peor de los casos subiremos durante 10 minutos. Y pensamos si nos conviene o no. Esta es una pregunta de negocios. Necesitamos mostrar esta imagen a los responsables de las decisiones comerciales y preguntar: “¿Cuánto tiempo como máximo podemos estar acostados en caso de un problema? ¿Podemos acostarnos en la peor situación durante 3-5 minutos? Y tomas una decisión.
Y aquí hay un punto interesante. Tenemos un par de informes sobre Patroni en la conferencia. Y tal vez lo estés usando. Esta es una conmutación por error automática para Postgres. GitLab y Data Egret hablaron sobre esto.
Y si tiene una conmutación por error automática que se produce en 30 segundos, ¿quizás podamos acostarnos durante 10 minutos? Porque cambiaremos a la réplica en este punto, y todo estará bien. Este es un punto discutible. No sé una respuesta clara. Siento que este tema no se trata solo de la recuperación de fallas.
Si tenemos una larga recuperación después de un fracaso, nos sentiremos incómodos en muchas otras situaciones. Por ejemplo, en los mismos experimentos, cuando hacemos algo y a veces tenemos que esperar 10 minutos.
Todavía no iría demasiado lejos, incluso si tenemos una conmutación por error automática. Por regla general, valores como 64, 100 gigabytes son buenos valores. A veces incluso vale la pena elegir menos. En general, esta es una ciencia sutil.
Para realizar iteraciones, por ejemplo, max_wal_size =1, 8, debe repetir la operación en masa muchas veces. Lo hiciste. Y sobre la misma base quieres volver a hacerlo, pero ya lo has borrado todo. ¿Qué hacer?
Hablaré más adelante sobre nuestra solución, lo que hacemos para iterar en tales situaciones. Y este es el enfoque más correcto.
Pero en este caso, tuvimos suerte. Si, como dice aquí "BEGIN, DELETE, ROLLBACK", entonces podemos repetir DELETE. Es decir, si lo cancelamos nosotros mismos, entonces podemos repetirlo. Y físicamente a ti, los datos estarán en el mismo lugar. Ni siquiera te hinchas. Puede iterar sobre tales DELETES.
Este DELETE con ROLLBACK es ideal para el ajuste de puntos de control, incluso si no tiene laboratorios de bases de datos correctamente implementados.
Hicimos un plato con una columna "i". Postgres tiene columnas de utilidad. Son invisibles a menos que se soliciten específicamente. Estos son: ctid, xmid, xmax.
Ctid es una dirección física. Página cero, la primera tupla de la página.
Se puede ver que después de ROOLBACK la tupla se quedó en el mismo lugar. Es decir, podemos intentarlo de nuevo, se comportará de la misma manera. Esto es lo principal.
Xmax es el momento de la muerte de la tupla. Fue sellado, pero Postgres sabe que la transacción se revirtió, por lo que no importa si es 0 o si es una transacción revertida. Esto sugiere que es posible iterar sobre DELETE y verificar las operaciones masivas del comportamiento del sistema. Puedes hacer laboratorios de bases de datos para los pobres.
Se trata de programadores. Sobre DBA, también, siempre regañan a los programadores por esto: "¿Por qué estás haciendo operaciones tan largas y difíciles?". Este es un tema perpendicular completamente diferente. Antes había administración y ahora habrá desarrollo.
Obviamente, no nos hemos roto en pedazos. Está vacío. Es imposible no romper tal DELETE por un montón de millones de líneas en partes. Se hará durante 20 minutos, y todo se acostará. Pero, desafortunadamente, incluso los desarrolladores experimentados cometen errores, incluso en empresas muy grandes.
¿Por qué es importante romper?
-
Si vemos que el disco está duro, vamos a ralentizarlo. Y si estamos rotos, podemos agregar pausas, podemos ralentizar la aceleración.
-
Y no bloquearemos a otros durante mucho tiempo. En algunos casos, no importa, si está eliminando basura real en la que nadie está trabajando, lo más probable es que no bloquee a nadie excepto al trabajo de vacío automático, porque esperará a que se complete la transacción. Pero si elimina algo que otra persona puede solicitar, será bloqueado, habrá algún tipo de reacción en cadena. Se deben evitar las transacciones largas en sitios web y aplicaciones móviles.
Esto es interesante. A menudo veo que los desarrolladores preguntan: "¿Qué tamaño de paquete debo elegir?".
Está claro que cuanto mayor sea el tamaño del paquete, menor será la sobrecarga de la transacción, es decir, la sobrecarga adicional de las transacciones. Pero al mismo tiempo, el tiempo aumenta para esta transacción.
Tengo una regla muy simple: tome todo lo que pueda, pero no repase los ejecutables por segundo.
¿Por qué un segundo? La explicación es muy simple y comprensible para todos, incluso para personas sin conocimientos técnicos. Vemos una reacción. Tomemos 50 milisegundos. Si algo ha cambiado, nuestro ojo reaccionará. Si es menos, entonces más difícil. Si algo responde después de 100 milisegundos, por ejemplo, hizo clic con el mouse y le respondió después de 100 milisegundos, ya siente este ligero retraso. Un segundo ya se percibe como frenos.
En consecuencia, si dividimos nuestras operaciones masivas en ráfagas de 10 segundos, entonces corremos el riesgo de bloquear a alguien. Y funcionará durante unos segundos, y la gente ya lo notará. Por eso, prefiero no hacer más de un segundo. Pero al mismo tiempo, no lo divida muy finamente, porque la sobrecarga de la transacción será notable. La base será más dura y pueden surgir otros problemas diferentes.
Elegimos el tamaño del pack. En cada caso, podemos hacerlo de forma diferente. Se puede automatizar. Y estamos convencidos de la eficiencia del procesamiento de un paquete. Es decir, hacemos ELIMINACIÓN de un paquete o ACTUALIZACIÓN.
Por cierto, todo lo que estoy hablando no se trata solo de ELIMINAR. Como habrá adivinado, estas son operaciones masivas sobre datos.
Y vemos que el plan es excelente. Puede ver el escaneo de índice, el escaneo de solo índice es aún mejor. Y tenemos una pequeña cantidad de datos involucrados. Y menos de un segundo cumple. Súper.
Y todavía tenemos que asegurarnos de que no haya degradación. Sucede que los primeros paquetes funcionan rápidamente y luego empeora, empeora y empeora. El proceso es tal que necesitas probar mucho. Esto es exactamente para lo que son los laboratorios de bases de datos.
Y todavía tenemos que preparar algo para que nos permita seguir esto correctamente en producción. Por ejemplo, podemos escribir la hora en el registro, podemos escribir dónde estamos ahora y a quién hemos eliminado ahora. Y esto nos permitirá entender lo que está sucediendo más adelante. Y en caso de que algo salga mal, encuentre rápidamente el problema.
Si necesitamos verificar la eficiencia de las solicitudes y necesitamos iterar muchas veces, entonces existe un bot compañero. Él ya está listo. Es utilizado por docenas de desarrolladores diariamente. Y él sabe cómo dar una enorme base de datos de terabytes a pedido en 30 segundos, su propia copia. Y puede eliminar algo allí y decir REINICIAR, y eliminarlo nuevamente. Puedes experimentar con él de esta manera. Veo un futuro para esta cosa. Y ya lo estamos haciendo.
¿Qué son las estrategias de partición? Veo 3 estrategias de partición diferentes que están usando los desarrolladores del paquete.
El primero es muy simple. Tenemos una identificación numérica. Y dividámoslo en diferentes intervalos y trabajemos con eso. La desventaja es clara. En el primer segmento, podemos tener 100 líneas de basura real, en el segundo 5 líneas o ninguna, o todas las 1 líneas resultarán ser basura. Trabajo muy desigual, pero es fácil de romper. Tomaron la identificación máxima y la rompieron. Este es un enfoque ingenuo.
La segunda estrategia es un enfoque equilibrado. Se utiliza en Gitlab. Tomaron y escanearon la mesa. Encontramos los límites de los paquetes de identificación para que cada paquete tuviera exactamente 10 registros. Y ponerlos en una cola. Y luego procesamos. Puedes hacer esto en varios hilos.
En la primera estrategia, también, por cierto, puedes hacer esto en varios hilos. No es difícil.
Pero hay un enfoque más fresco y mejor. Esta es la tercera estrategia. Y cuando es posible, es mejor elegirlo. Hacemos esto sobre la base de un índice especial. En este caso, lo más probable es que sea un índice de acuerdo con nuestra condición de basura e ID. Incluiremos el ID para que sea un escaneo de índice solamente para que no vayamos al montón.
Por lo general, el escaneo de solo índice es más rápido que el escaneo de índice.
Y encontramos rápidamente nuestras identificaciones que queremos eliminar. BATCH_SIZE que seleccionamos de antemano. Y no solo los conseguimos, los conseguimos de una manera especial e inmediatamente los hackeamos. Pero estamos bloqueando para que si ya están bloqueados, no los bloqueemos, sino que avancemos y tomemos los siguientes. Esto es para el salto de actualización bloqueado. Esta súper característica de Postgres nos permite trabajar en varios subprocesos si queremos. Es posible en una secuencia. Y aquí hay un CTE: esta es una solicitud. Y tenemos una eliminación real en el segundo piso de este CTE: returning *. Puedes devolver la identificación, pero es mejor *si no tiene muchos datos en cada línea.
¿Por qué lo necesitamos? Esto es lo que tenemos que informar. Ahora hemos eliminado tantas líneas de hecho. Y tenemos bordes por ID o por created_at como este. Puedes hacer min, max. Se puede hacer otra cosa. Puedes meter mucho aquí. Y es muy conveniente para monitorear.
Hay una nota más sobre el índice. Si decidimos que necesitamos un índice especial para esta tarea, debemos asegurarnos de que no estropee las actualizaciones del montón solo de tuplas. Es decir, Postgres tiene tales estadísticas. Esto se puede ver en pg_stat_user_tables para su tabla. Puede ver si se están utilizando actualizaciones activas o no.
Hay situaciones en las que su nuevo índice simplemente puede cortarlos. Y tiene todas las demás actualizaciones que ya están funcionando, disminuya la velocidad. No solo porque apareció el índice (cada índice ralentiza un poco las actualizaciones, pero un poco), sino que aquí lo sigue arruinando. Y es imposible hacer una optimización especial para esta tabla. Esto sucede a veces. Esta es una sutileza que pocas personas recuerdan. Y este rastrillo es fácil de pisar. A veces sucede que necesita encontrar un enfoque desde el otro lado y aún prescindir de este nuevo índice, o hacer otro índice, o de alguna otra manera, por ejemplo, puede usar el segundo método.
Pero esta es la estrategia más óptima, cómo dividir en lotes y disparar en lotes con una sola solicitud, eliminar un poco, etc.
Transacciones largas
Autovacío bloqueado -
problema de bloqueo -
El error #5 es grande. Nikolai de Okmeter habló sobre el monitoreo de Postgres. El monitoreo ideal de Postgres, desafortunadamente, no existe. Algunos están más cerca, algunos están más lejos. Okmeter está lo suficientemente cerca de ser perfecto, pero falta mucho y es necesario agregarlo. Tienes que estar preparado para esto.
Por ejemplo, las tuplas muertas se supervisan mejor. Si tienes muchas cosas muertas en la mesa, entonces algo anda mal. Es mejor reaccionar ahora, de lo contrario puede haber degradación y podemos acostarnos. Sucede.
Si hay un IO grande, entonces está claro que esto no es bueno.
Transacciones largas también. Las transacciones largas no deben permitirse en OLTP. Y aquí hay un enlace a un fragmento que le permite tomar este fragmento y ya hacer un seguimiento de las transacciones largas.
¿Por qué las transacciones largas son malas? Porque todos los bloqueos se liberarán solo al final. Y jodemos a todos. Además, bloqueamos el autovacío para todas las mesas. No es bueno en absoluto. Incluso si tiene habilitado el modo de espera en caliente en la réplica, sigue siendo malo. En general, en ninguna parte es mejor evitar transacciones largas.
Si tenemos muchas mesas que no se aspiran, entonces necesitamos tener una alerta. Aquí tal situación es posible. Podemos afectar indirectamente al funcionamiento del autovacío. Este es un fragmento de Avito, que mejoré ligeramente. Y resultó ser una herramienta interesante para ver lo que tenemos con autovacuum. Por ejemplo, algunas mesas están esperando allí y no esperarán su turno. También necesita ponerlo en monitoreo y tener una alerta.
Y emite bloques. Bosque de árboles de bloque. Me gusta tomar algo de alguien y mejorarlo. Aquí tomé un CTE recursivo genial de Data Egret que muestra un bosque de árboles de bloqueo. Esta es una buena herramienta de diagnóstico. Y sobre esta base, también puede construir monitoreo. Pero esto debe hacerse con cuidado. Necesita hacer una pequeña declaración_tiempo de espera para usted. Y lock_timeout es deseable.
A veces todos estos errores ocurren en suma.
En mi opinión, el principal error aquí es organizativo. Es organizativo, porque la técnica no tira. Este es el número 2: se registraron en el lugar equivocado.
Verificamos en el lugar equivocado, porque no teníamos un clon de producción, lo cual es fácil de verificar. Es posible que un desarrollador no tenga acceso a la producción en absoluto.
Y no comprobamos allí. Si hubiéramos mirado allí, lo habríamos visto nosotros mismos. El desarrollador lo vio todo incluso sin un DBA si lo comprobó en un buen entorno, donde hay la misma cantidad de datos y una ubicación idéntica. Habría visto toda esta degradación y estaría avergonzado.
Más sobre autovacío. Después de haber realizado un barrido masivo de varios millones de líneas, todavía tenemos que hacer REPACK. Esto es especialmente importante para los índices. Se sentirán mal después de que hayamos limpiado todo allí.
Y si desea recuperar el trabajo de limpieza diario, le sugiero que lo haga con más frecuencia, pero en menor cantidad. Puede ser una vez por minuto o incluso más a menudo un poco. Y debe controlar dos cosas: que esta cosa no tenga errores y que no se quede atrás. El truco que mostré solo resolverá esto.
Lo que hacemos es de código abierto. Está publicado en GitLab. Y lo hacemos para que las personas puedan verificar incluso sin un DBA. Estamos haciendo un laboratorio de base de datos, es decir, llamamos al componente base en el que Joe está trabajando actualmente. Y puede obtener una copia de la producción. Ahora hay una implementación de Joe para slack, puede decir allí: "explicar tal y tal solicitud" e inmediatamente obtener el resultado de su copia de la base de datos. Incluso puedes ELIMINAR allí, y nadie lo notará.
Digamos que tiene 10 terabytes, hacemos laboratorio de base de datos también 10 terabytes. Y con bases de datos simultáneas de 10 terabytes, 10 desarrolladores pueden trabajar simultáneamente. Todos pueden hacer lo que quieran. Puede eliminar, soltar, etc. Eso es una fantasía. Hablaremos de esto mañana.
Esto se denomina aprovisionamiento ligero. Este es un aprovisionamiento sutil. Esta es una especie de fantasía que elimina en gran medida los retrasos en el desarrollo, en las pruebas y hace del mundo un lugar mejor en este sentido. Es decir, solo le permite evitar problemas con las operaciones masivas.
Ejemplo: base de datos de 5 terabytes, obteniendo una copia en menos de 30 segundos. Y ni siquiera depende del tamaño, es decir, no importa cuántos terabytes.
Hoy puedes ir a y profundizar en nuestras herramientas. Puedes registrarte para ver lo que hay. Puedes instalar este bot. Es gratis. Escribir.
preguntas
Muy a menudo, en situaciones reales, resulta que los datos que deberían permanecer en la tabla son mucho menos de los que deben eliminarse. Es decir, en tal situación, a menudo es más fácil implementar dicho enfoque, cuando es más fácil crear un nuevo objeto, copiar allí solo los datos necesarios y troncar la tabla anterior. Está claro que se necesita un enfoque programático para este momento, mientras se cambia. ¿Cómo es este enfoque?
Este es un muy buen enfoque y una muy buena tarea. Es muy similar a lo que hace pg_repack, es muy similar a lo que tienes que hacer cuando haces IDs de 4 bytes. Muchos marcos hicieron esto hace unos años, y solo las placas han crecido y deben convertirse a 8 bytes.
Esta tarea es bastante difícil. Lo hicimos. Y hay que tener mucho cuidado. Hay candados, etc. Pero se está haciendo. Es decir, el enfoque estándar es ir con pg_repack. Usted declara tal etiqueta. Y antes de comenzar a cargar datos de instantáneas, también declara una placa que rastrea todos los cambios. Hay un truco que puede que ni siquiera rastree algunos cambios. Hay sutilezas. Y luego cambias rodando cambios. Habrá una breve pausa cuando cerremos a todos, pero en general esto se está haciendo.
Si observa pg_repack en GitHub, entonces, cuando hubo una tarea para convertir una ID de int 4 a int 8, entonces hubo una idea de usar pg_repack en sí. Esto también es posible, pero es un poco complicado, pero también funcionará para esto. Puede intervenir en el disparador que usa pg_repack y decir allí: "No necesitamos estos datos", es decir, solo transferimos lo que necesitamos. Y luego simplemente cambia y eso es todo.
Con este enfoque, todavía obtenemos una segunda copia de la tabla, en la que los datos ya están indexados y apilados de manera muy uniforme con hermosos índices.
Bloat no está presente, es un buen enfoque. Pero sé que hay intentos de desarrollar una automatización para esto, es decir, hacer una solución universal. Puedo ponerte en contacto con esta automatización. Está escrito en Python, lo cual es bueno.
Solo soy un poco del mundo de MySQL, así que vine a escuchar. Y usamos este enfoque.
Pero es sólo si tenemos el 90%. Si tenemos el 5%, entonces no es muy bueno usarlo.
¡Gracias por el informe! Si no hay recursos para hacer una copia completa de prod, ¿hay algún algoritmo o fórmula para calcular la carga o el tamaño?
Buena pregunta. Hasta ahora, podemos encontrar bases de datos de varios terabytes. Incluso si el hardware no es el mismo, por ejemplo, menos memoria, menos procesador y los discos no son exactamente iguales, pero aún así lo hacemos. Si no hay absolutamente nada, entonces debes pensar. Déjame pensar hasta mañana, viniste, hablamos, esta es una buena pregunta.
¡Gracias por el informe! Primero comenzó con el hecho de que existe un Postgres genial, que tiene tales y tales limitaciones, pero se está desarrollando. Y todo esto es una muleta en general. ¿No está todo esto en conflicto con el propio desarrollo de Postgres, en el que aparecerá algún deferente DELETE u otra cosa que debería mantener en un nivel bajo lo que estamos tratando de manchar con algunos de nuestros extraños medios aquí?
Si dijimos en SQL eliminar o actualizar muchos registros en una transacción, ¿cómo puede Postgres distribuirlo allí? Estamos físicamente limitados en las operaciones. Todavía lo haremos durante mucho tiempo. Y vamos a bloquear en este momento, etc.
Hecho con índices.
Puedo suponer que el mismo ajuste del punto de control podría automatizarse. Algún día podría ser. Pero entonces realmente no entiendo la pregunta.
La pregunta es, ¿existe tal vector de desarrollo que va aquí y allá, y aquí el tuyo va paralelo? Aquellos. ¿Aún no lo han pensado?
Hablé sobre los principios que se pueden usar ahora. hay otro bot , con esto puede hacer un ajuste de punto de control automatizado. ¿Algún día estará en Postgres? No sé, ni siquiera se ha hablado todavía. Todavía estamos lejos de eso. Pero hay científicos que hacen nuevos sistemas. Y nos meten en índices automáticos. Hay desarrollos. Por ejemplo, puede mirar el ajuste automático. Selecciona los parámetros automáticamente. Pero todavía no hará el ajuste del punto de control por usted. Es decir, mejorará el rendimiento, el búfer de shell, etc.
Y para el ajuste del punto de control, puede hacer esto: si tiene miles de clústeres y hardware diferente, diferentes máquinas virtuales en la nube, puede usar nuestro bot hacer automatización. Y max_wal_size se seleccionará automáticamente de acuerdo con la configuración de su objetivo. Pero hasta ahora esto no está ni siquiera cerca en el núcleo, desafortunadamente.
Buenas tardes Usted habló sobre los peligros de las transacciones largas. Dijiste que el vacío automático está bloqueado en caso de eliminaciones. ¿De qué otra manera nos hace daño? Porque estamos hablando más de liberar espacio y poder usarlo. ¿Qué más nos falta?
Autovacuum quizás no sea el mayor problema aquí. Y el hecho de que una transacción larga puede bloquear otras transacciones, esta posibilidad es más peligrosa. Ella puede o no encontrarse. Si ella conoció, entonces puede ser muy malo. Y con autovacuum, esto también es un problema. Hay dos problemas con las transacciones largas en OLTP: bloqueos y autovacío. Y si tiene habilitada la retroalimentación de espera en caliente en la réplica, aún recibirá un bloqueo de vacío automático en el maestro, llegará desde la réplica. Pero al menos no habrá bloqueos. Y habrá loks. Estamos hablando de cambios de datos, por lo que los bloqueos son un punto importante aquí. Y si esto es todo por mucho, mucho tiempo, entonces se bloquean más y más transacciones. Pueden robar a otros. Y aparecen árboles de lok. Proporcioné un enlace al fragmento. Y este problema se vuelve más notorio más rápido que el problema con el vacío automático, que solo puede acumularse.
¡Gracias por el informe! Comenzó su informe diciendo que hizo la prueba incorrectamente. Continuamos con nuestra idea de que necesitamos llevar el mismo equipo, con la base de la misma manera. Digamos que le dimos una base al desarrollador. Y cumplió con el pedido. Y él parece estar bien. Pero él no verifica en vivo, sino en vivo, por ejemplo, tenemos una carga del 60-70%. E incluso si usamos esta afinación, no funciona muy bien.
Es importante contar con un experto en el equipo y utilizar expertos DBA que puedan predecir lo que sucederá con una carga de fondo real. Cuando acabamos de impulsar nuestros cambios limpios, vemos la imagen. Pero un enfoque más avanzado, cuando volvimos a hacer lo mismo, pero con una carga simulada con producción. Es bastante genial. Hasta entonces, tienes que crecer. Es como un adulto. Solo miramos lo que tenemos y también miramos si tenemos suficientes recursos. Buena pregunta.
Cuando ya estamos haciendo una selección basura y tenemos, por ejemplo, una bandera eliminada
Esto es lo que autovacuum hace automáticamente en Postgres.
Ah, ¿lo hace?
Autovacuum es el recolector de basura.
Gracias!
¡Gracias por el informe! ¿Existe una opción para diseñar inmediatamente una base de datos con particiones de tal manera que toda la basura se ensucie de la tabla principal en algún lugar lateral?
Por supuesto que lo hay.
¿Es posible entonces protegernos si hemos cerrado con llave una mesa que no se debe utilizar?
Por supuesto que tengo. Pero es como una pregunta sobre el huevo y la gallina. Si todos sabemos lo que sucederá en el futuro, entonces, por supuesto, haremos todo bien. Pero el negocio está cambiando, hay nuevas columnas, nuevas solicitudes. Y luego, vaya, queremos eliminarlo. Pero esta situación ideal, en la vida se da, pero no siempre. Pero en general es una buena idea. Sólo truncar y eso es todo.
Fuente: habr.com