Видео

¡Muchísimas gracias! 😊

¡Gracias por tu comentario y por ver nuestro webinar! Tienes toda la razón, el balanceo es un tema relativamente sencillo en comparación con la consistencia de datos entre instancias, que presenta más desafíos. Nos encantaría profundizar más en ese tema. Con todo, en futuros webinars abordaremos las mejores prácticas para asegurar la consistencia de datos en entornos distribuidos con PostgreSQL. ¡Sigue atento a nuestras próximas publicaciones! Mientras tanto, si tienes alguna duda específica o tema en mente, no dudes en compartirlo con nosotros.

Lameentablemente no. Sin embargo en las últimas versiones han aparecido las vistas pg_stat_progress_* que muestran información del avance de ciertos comandos. Estos comandos al día de hoy son: ANALYZE, VACUUM, CLUSTER / VACUUM FULL, CREATE INDEX, COPY y un base backup. Esta información no la expresa en tiempo transcurrido / tiempo restante sino en bloques de disco procesados / bloques de disco ha procesar (también incluye información de la fase o la etapa del proceso y aveces del número de regsitros procesados y cuantos se deben procesar). La razón para mostrar la información de este modo es: 1) te permite determinar el tiempo restante, por ejemplo si se demoró 10min en procesar el 10% de los bloques de disco se debe demorar el proceso aproximadamente 90min más (aun falta procesar el 90%) 2) los cálculos de tiempo no son exactos porque en el camino se puede encontrr conque algún otro proceso esta consumiendo el ancho de banda del disco, la memoria o el cpu y eso afectará a la rápidez con que procesa los bloques faltantes. Si quieres saber que vistas pg_stat_progress_* existen y que columnas tienen, haz clic en este enlace que te llevará a la sección apropiada de la documentación de postgres: www.postgresql.org/docs/current/progress-reporting.html

@@systemguards7746 Gracias fue de mucha ayuda.

¡Muchas gracias a ti por comentar el video! En cuanto a tu consulta..., el rendimiento se verá afectado a medida que se vayan anonimizando los datos. De hecho, cada medida de seguridad tiende a afectar el rendimiento. Debido a eso, es necesario realizar un análisis de los datos con la finalidad de determinar qué anonimizar y qué no. Esta es toda una metodología que se ejecuta y que, a lo largo del camino, lleva a determinar temas como: niveles de riesgo de reidentificación del registro, tipos de datos y método de anonimización entre otras cosas. Una forma, tal vez, de agilitar las consultas de gran volúmen de datos es particionar las tablas. Sin embargo, esto depende de la lógica de negocio la cual determinará si es factible o no este camino.

No existe alguna documentación de PostgreSQL que indique en qué lugar es más seguro configurar. Sin embargo, las sentencias ejecutadas en psql sirven para configurar parámetros específicos y no permitirán realizar algún cambio adicional, lo que sí podría pasar si se ingresa a modificar el archivo propiamente dicho. También es necesario recalcar, que si se realizan los cambios directamente en el archivo, será difícil tener un registro de las modificaciones realizadas a lo largo del tiempo. Por otra parte, si se ejecuta los comandos en psql se generará un archivo llamado postgresql.auto.conf en el que se registrarán exclusivamente los parámetros que se han ajustado.

Eso depende muy particularmente de la estrategia de seguridad que se esté implementando en la que deberán analizarse variables como la criticidad de la información. Sin embargo, se puede plantear una infraestructura de replicación de datos en la cual intrínsecamente se están respaldando los datos. Además existe la posibilidad de balancear la carga del servidor, pudiendo tener un equipo para escritura y otro para lectura de datos, fuera del servidor de respaldos, el cuál se convertiría en otra instancia más en la que reposarán los datos. Con respecto a Barman..., técnicamente es posible, ya que fue diseñado para eso. Pero, obviamente, se debe determinar qué versiones de Postgres son soportadas por una versión de Barman específica. En el caso de Barman 3.0, serían las versiones de Postgres desde la 15 hasta la 10. Aún así, también hay que evaluar las opciones soportadas. Por ejemplo, para Postgres 15 no se soportan los backups exclusivos sino solo concurrentes, por lo que podría verse afectada alguna configuración de los backups de versiones anteriores de PostgreSQL.

Por favor, escríbenos al correo info@systemguards.com.ec. Con gusto te daremos más información sobre el tema.

SYSTEMGUARDS ofrece una variedad de capacitaciones en español que cubren todas las áreas del PostgreSQL comunitario. Por favor, contáctanos al correo info@systemguards.com.ec. Con gusto te proporcionaremos más información sobre nuestros cursos.