Destripando el sistema de replicación de PostgreSQL 9.0 Ernesto Quiñones A. - CTO
Advertencia! Esta charla es para explicar como funciona por dentro el sistema de replicación de PostgreSQL 9.0 no para enseñar a instalar un sistema de replicación. Porque? Lo otro lo pueden aprender leyendo el manual.
Que es un sistema de replicación de base de datos? En simple: es mantener una 2da base de datos alterna con la data idéntica a la principal.
Porque debería tener un sistema de replicación para mi dbms? Para tener un sistema tolerable a fallas. Para balancear la carga de trabajo en diversos servidores. Para aplicaciones de alto consumo en consultas (B.I.) Para tener un ambiente de pruebas o desarrollo lo más parecido al ambiente de producción. Muchas otras que se puedan imaginar..
OK Por donde empezamos?
Características de la replicación interna de PgSQL 9.0 Es Streaming Replication Hot Standby No requiere hardware especial No requiere de servidores/servicios especiales No sobrecarga el servidor principal No requiere de un sistema de resolución de conflictos (al menos no adicionales al que ya implementa la base de datos) Si se cayera la replicación al menos tendré acceso de lectura Point-In-Time Recovery, es decir permite recuperar la data al tiempo pasado más cercano donde esta se encuentre bien. Usa WAL como método de cache, esta técnica permite asegurar que solo las operaciones bien realizadas actualicen la data (atomicidad y durabilidad).
Qué no hay? Múltiples servidores maestros/principales Asegurar que ante una falla el servidor principal nunca va a perder la data Controlar la replicación a nivel de tablas
Como funciona? En simple es: Servidor primario Servidor secundario pg_xlog/ WAL Data Conexión de red Traspasando datos pg_xlog/ WAL Data
El WAL es... Básicamente es un buffer donde se llevan a cabo las operaciones a la data y una vez terminada se pasan al almacenamiento de datos principal, si algo pasara entonces el área de datos permanecerá intacto solo se perderá lo que esta en el WAL. WAL genera segmentos de data de 16mb (configurable) en archivos físicos que tiene páginas de datos de 8kb (configurable).
El WAL es... typedef struct XLogRecord { pg_crc32 xl_crc; /* CRC for this record */ XLogRecPtr xl_prev; /* ptr to previous record in log */ TransactionId xl_xid; /* xact id */ uint32 xl_tot_len; /* total len of entire record */ uint32 xl_len; /* total len of rmgr data */ uint8 xl_info; /* flag bits, see below */ RmgrId xl_rmid; /* resource manager for this record */ } XLogRecord; typedef struct XLogRecData { char *data; /* start of rmgr data to include */ uint32 len; /* length of rmgr data to include */ Buffer buffer; /* buffer associated with data, if any */ bool buffer_std; /* buffer has standard pd_lower/pd_upper */ struct XLogRecData *next; /* next struct in chain, or NULL */ } XLogRecData; typedef struct CheckpointStatsData { TimestampTz ckpt_start_t; /* start of checkpoint */ TimestampTz ckpt_write_t; /* start of flushing buffers */ TimestampTz ckpt_sync_t; /* start of fsyncs */ TimestampTz ckpt_sync_end_t; /* end of fsyncs */ TimestampTz ckpt_end_t; /* end of checkpoint */ int ckpt_bufs_written; /* # of buffers written */ int ckpt_segs_added; /* # of new xlog segments created */ int ckpt_segs_removed; /* # of xlog segments deleted */ int ckpt_segs_recycled; /* # of xlog segments recycled */ } CheckpointStatsData;
El WAL es... Una ventaja del WAL es que puede residir en cualquier directorio y podemos hacer un enlace simbólico al directorio donde debería residir. En caso de que suceda un problema el WAL puede retroceder hacia el pasado hasta el último momento en que todo estuvo ok.
El WAL es... WAL maneja varios niveles para especificar que tanto deseo almacenar en este buffer en el nivel mínimo solo contiene información para recuperar una db en caso de paradas abruptas del servicio. Para realizar la replicación requerimos aumentar el nivel de WAL para reconstruir toda la data de una db.
El primer paso: indicar donde copiaremos el WAL En los archivos de configuración debemos indicar donde vamos a duplicar nuestros WAL files tomaremos en cuenta que debe existir una comunicación en ese file system entre los 2 servidores. Se puede usar NFS para ello, quizás (aún no lo he probado) podría usarse SSHFS como una forma más sencilla. Para asegurar que se copiarán todas las transacciones haremos que se mantenga un buen numero de segmentos WAL historicamente, pasar data por red tiene una demora importante que debemos tener en cuenta.
El primer paso: indicar donde copiaremos el WAL Servidor Principal NFS ó SSH Server Conexión LAN Servidor Replica NFS Client ó SSHFS client NFS: * Más complicado de configurar * Más rápido porque funciona a nivel de protocolo más bajo y coordinado con el kernel. * Menos seguro en la transmisión? SSHFS: * Más simple de configurar * Más lento que NFS, 1 a 2, porque funciona en capa más alta de tcp/ip y básicamente es un SCP. * Más seguro en la transmisión?
El segundo paso: reconstruir la imagen inicial de la db en el servidor de destino. La Herramienta más popular para esto es Rsync. Rsync trabaja en base a deltas binarios para determinar los cambios bit a bit entre 2 árboles de directorio y los files que este contiene. Se saca un checksum (md5) de los contenidos para verificar contra el espejo que es lo que ha cambiado. En los 2 anteriores pasos mencionados hasta el momento existen algunas ventajas, estamos limitados a replicar únicamente a un solo servidor, podemos realizar esto en varios y en cascada, otra es que podemos hacer esto casi en caliente.
Tercer paso: configurar el servidor réplica solo como servidor de consulta. Dado que las transacciones se manejarán en el servidor principal en las réplicas no podemos más que procesar consultas, ambos servicios no pueden escribir en la zona del WAL. Esto es un servidor HOTSTANDBY
HOTSTANDBY Hotstandby permite a PostgreSQL correr querys solo de consulta, de forma generica el estado Hotstandby permite recuperarse hasta un estado consistente a una db mientras esta sigue atendiendo conexiones. En la replica podemos ejecutar estos tipos de queries: Query access - SELECT, COPY TO Cursor commands - DECLARE, FETCH, CLOSE Parameters - SHOW, SET, RESET Transaction management commands BEGIN, END, ABORT, START TRANSACTION SAVEPOINT, RELEASE, ROLLBACK TO SAVEPOINT EXCEPTION blocks and other internal subtransactions LOCK TABLE, though only when explicitly in one of these modes: ACCESS SHARE, ROW SHARE or ROW EXCLUSIVE. Plans and resources - PREPARE, EXECUTE, DEALLOCATE, DISCARD Plugins and extensions - LOAD
HOTSTANDBY Uno podría iniciar una transacción pero el sistema nunca le asignará un espacio en el WAL por lo tanto nunca se grabará nada Los principales problemas que se pueden presentar son: Locks de Accesos Exclusivos en el servidor principal que bloquean tablas en la réplica. Borrar tablespace en el servidor principal que crean conflictos con queries que los usan en la réplica. Borrar una base de datos en el servidor principal y que en la replica existan conexiones a esta db. Correr un full vacuum mientras el WAL de la réplica aún tiene visible la fila. El mismo caso del anterior pero un query tiene acceso a las páginas a borrar.
HOTSTANDBY En la mayoría de los casos el problema genera un delay, este puede ser demasiado grande debido al control de concurrencias por ejemplo: * servidor réplica lanza un query con lock exclusivo sobre una tabla enorme que toma 15 * llega un drop table del servidor primario * servidor réplica sigue procesando el query * servidor primario sigue trabajando normalmente * servidor replica tiene paradas las transacciones replicadas del servidor primario hasta que no acabe el query en la réplica * termina el query en el servidor réplica y por fin aplica los otros cambios encolados * tenemos 15 minutos de retraso si es que no pasa de nuevo Para ello es deseable configurar el tiempo de espera para procesar el WAL y no tener este tipo de problemas, los queries que sobrepasen este tiempo serán abortados.
Qué falta? Pues nada, iniciar el servidor réplica, durante este inicio y mientras la db se sincroniza con el servidor principal las conexiones de clientes no estarán disponibles hasta que se llegue a un punto en el cual la información ya es consistente. Luego de este paso todo esta listo, tenemos un servidor de réplica corriendo :-)
Toda la documentación de esta exposición la pueden encontrar aquí : http://tinyurl.com/3wuugpq O en simple: http//www.eqsoft.net/wiki (sección Nuestras Ponencias)
Gracias por su tiempo.