Usando repmgr para autofailover con PostgreSQL

Transcripción

1 Jaime Casanova 2ndQuadrant 3 de noviembre de 2011

2 Quién soy yo? Permítanme presentarme Miembro de la comunidad de PostgreSQL desde el 2004 Contacto Regional de PostgreSQL para el Ecuador Beta-tester Revisor de parches Administrador del Grupo de Usuarios de PostgreSQL del Ecuador: Consultor de la empresa 2ndQuadrant

3 Tabla de Contenido 1 Introducción 2 3

4 Qué es repmgr? Una herramienta de línea de comandos que simplifica: Creación Administración Monitoreo... provee buenas prácticas... (v2.0) detecta fallas en el cluster y reacciona en consecuencia

5 Requisitos Introducción PostgreSQL 9.0+ Streaming Replication Hot Standby rsync

6 El objetivo de repmgr Un maestro Varios esclavos

7 Comandos Introducción master register standby register clone promote follow

8 Comandos (v2.0) witness create cluster show

9 Tabla de Contenido 1 Introducción 2 3

10 Agregar un nodo repmgr standby clone Agrega un nuevo nodo, ocupandose de los detalles.

11 Agregar un nodo repmgr standby clone Agrega un nuevo nodo, ocupandose de los detalles.

12 Failover Introducción repmgr standby promote Promueve un standby a master Nosotros indicamos el standby que debe ser promovido... y debemos lidiar con la posibilidad de que el antiguo maestro reaparezca

13 Failover Introducción repmgr standby follow Detecta el nuevo master en el cluster y apunta este standby hacia ese maestro

14 Para que necesitamos repmgr? 1 En PostgreSQL no hay forma fácil de saber que nodo promover 2 PostgreSQL destruiría el cluster al promover un nodo

15 Qué nodo promover? Qué nodo había replicado más información del maestro?

16 Qué nodo promover? postgres=# SELECT pg_last_xlog_replay_location(); -[ RECORD 1 ] pg_last_xlog_replay_location 0/1CBB7550

17 Qué nodo promover? postgres=# select * from repmgr_pgbr.repl_status ord -[ RECORD 1 ] [ RECORD 2 ] primary_node 1 standby_node 2 standby_name marte last_monitor_time :48: last_wal_primary_location 0/1D1156B4 last_wal_standby_location 0/1D1156B4 replication_lag 0 bytes apply_lag 516 bytes time_lag 00:00: primary_node 1 standby_node 3 standby_name pluton last_monitor_time Usando repmgr para autofailover con13:48: PostgreSQL

18 Para esto necesitamos repmgr Simplifica la creación del cluster Facilita escoger un nuevo master en caso de necesitarlo No destruyo el cluster en el proceso Ayuda a los standby restantes a detectar al nuevo master El único nodo que debe ser reconstruido es el antiguo master (repmgr standby clone force)

19 Tabla de Contenido 1 Introducción 2 3

20 Diseño Introducción Se requiere un número impar de nodos Utiliza memoria compartida en PostgreSQL (repmgr_funcs) Utiliza el monitoreo como un heartbeat para detectar la falla del master El nuevo master es el nodo que más ha replicado y que pueda ver a la mayoría de los nodos del cluster Se requiere de un script que realize el failover

21 Logrando imparidad repmgr witness create Agrega un nodo witness (testigo) No es un standby Solo copia información de configuración del cluster

22 Se necesita mayoría

23 Paro cardiaco El heartbeat detecta el fallo Y espera un tiempo antes de decidir que esta muerto

24 Empiezan las elecciones Todos los nodos indican su oferta de campaña en memoria compartida Si repmgrd no está corriendo en algun nodo, este no tendrá oferta de campaña Cada nodo decide cual es la mejor oferta y decide que el nodo con esa oferta será el nuevo master Se puede tener favoritos (parámetro priority)

25 Failover Introducción repmgr standby promote/follow Cambio de ip en el servidor STONITH cualquier otra acción que deseen...

26 Failover Introducción parametro promote_command parametro follow_command

27 Más información Website - Public GIT - IRC channel - freenode #repmgr Mailing-list -

28 failback Introducción repmgr standby promote -h audiencia repmgr standby follow -h jaime