En los últimos años se ha visto una creciente adopción de PostgreSQL. PostgreSQL es una increíble base de datos relacional. En cuanto a las características, está entre los mejores, si no el mejor. Hay muchas cosas que me encantan:PL/PG SQL, valores predeterminados inteligentes, replicación (que realmente funciona desde el primer momento) y una comunidad de código abierto activa y dinámica. Sin embargo, más allá de las características, hay otros aspectos importantes de una base de datos que deben tenerse en cuenta. Si planea crear una gran operación 24 horas al día, 7 días a la semana, la capacidad de operar fácilmente la base de datos una vez que esté en producción se convierte en un factor muy importante. En este aspecto, PostgreSQL no aguanta muy bien. En esta publicación de blog, detallaremos algunos de estos desafíos operativos con PostgreSQL. No hay nada fundamentalmente irreparable aquí, solo una cuestión de priorización. Con suerte, podemos generar suficiente interés en la comunidad de código abierto para priorizar estas funciones.
1. Sin detección automática de controlador de cliente de conmutación por error maestra
El controlador de cliente de PostgreSQL no detecta automáticamente cuando se ha producido una conmutación por error del maestro (y se ha elegido un nuevo maestro). Para solucionar esto, los administradores deben implementar una capa de proxy en el lado del servidor. Las opciones populares son el mapeo de DNS, el mapeo de IP virtual, PgPool y HAProxy. Se puede hacer que todas estas opciones funcionen bien, pero se requiere un aprendizaje adicional significativo y un esfuerzo administrativo. En el caso de que se introduzca un proxy en la ruta de datos, también hay un impacto considerable en el rendimiento. Esta es una función integrada estándar en muchas de las nuevas bases de datos NoSQL, y PostgreSQL sería genial para sacar una hoja de sus libros cuando se trata de operaciones.
2. Sin conmutación por error automática integrada entre el maestro y el modo de espera
Cuando falla un maestro de PostgreSQL, uno de los servidores en espera debe elegirse como maestro. Este mecanismo no está integrado en PostgreSQL. Por lo general, se utilizan herramientas de software de terceros como Patroni, Pacemaker, etc. para manejar este escenario. ¿Por qué no tener esto integrado en el servidor? Estas herramientas de terceros parecen engañosamente simples, pero requieren un esfuerzo, conocimiento y pruebas considerables por parte del administrador para hacerlo bien. Al integrar esto en la base de datos, le está haciendo un gran favor al administrador de su base de datos.
Facilitando la administración de una base de datos #PostgreSQLHaga clic para twittear3. Actualización importante sin cero tiempo de inactividad
No es posible actualizar su base de datos PostgreSQL de una versión principal a otra sin tiempo de inactividad. Básicamente, debe apagar todos sus servidores y usar pg_upgrade para actualizar sus datos a la versión más nueva. El tiempo de inactividad no es grande ya que no hay copia de datos involucrada, sin embargo, todavía hay tiempo de inactividad. Si está ejecutando una operación las 24 horas del día, los 7 días de la semana, es posible que esta no sea una opción para usted.
Con el lanzamiento de la replicación lógica, tenemos una opción alternativa para la actualización en línea.
- Cree una nueva configuración Master-Standby de PostgreSQL con la nueva versión.
- Configure la replicación lógica para replicar desde la versión anterior a la versión más nueva.
- Una vez que esté listo, cambie su cadena de conexión para que apunte desde la configuración anterior a la nueva configuración.
Nuevamente, esto puede funcionar, pero la sobrecarga es enorme. Idealmente, lo que se necesita aquí es una forma de actualizar en el lugar de manera continua sobre una configuración maestra de reserva. La actualización de MySQL le permite actualizar sus esclavos en el lugar a la nueva versión y luego activar una conmutación por error.
4. Sin VACÍO LLENO en el lugar
Autovacuum/VACUUM es muy útil y ayuda a solucionar este problema hasta cierto punto. Debe examinar regularmente la hinchazón en sus mesas para asegurarse de que la configuración de vacío automático sea adecuada y funcione bien para su mesa. Sin embargo, autovacuum no llega hasta el final; en realidad, no termina fusionando y eliminando las páginas. Si tiene una gran cantidad de actualizaciones, inserte y elimine cargas de trabajo, sus páginas terminarán fragmentadas, lo que afectará su rendimiento. La única forma de evitar esto es ejecutar VACUUM FULL que básicamente reconstruirá todas las páginas para eliminar la fragmentación. Sin embargo, este proceso solo se puede realizar con tiempo de inactividad:su mesa está inactiva durante el VACÍO LLENO. Para grandes conjuntos de datos, esto puede llevar varias horas y no es una alternativa práctica si desea ejecutar una operación las 24 horas, los 7 días de la semana.
Nota:la comunidad ya comenzó a trabajar en el motor de almacenamiento zheap que supera esta limitación.
Si hay otras mejoras que cree que serían útiles, no dude en dejar un comentario.
