PostgreSQL

Transcripción

PostgreSQL

PostgreSQL
Agenda
• Backup Continuo PITR
• Streaming Replication
• Nuevas Funcionalidades 9.2 y 9.3
Nicolas Domínguez Florit [email protected]
Ignacio Bisso
[email protected]
PostgreSQL
Backup Continuo
Estrategia de Backup
Es frecuente pensar al backup como el Proceso para obtener
una copia de seguridad con el objetivo de ser restaurada
ante una eventual pérdida de datos.
FRECUENTES PUNTOS DEBILES
VENTANA
- Lo Configuramos, lo ponemos a
. PERDIDA
DE
funcionar y nos olvidamos.
- No analizamos la Ventana de Pérdida y
PERIODICIDAD
sus efectos sobre las aplicaciones
DOWN - TIME
- No se hacen pruebas de restore, ni
verificamos si se genera OK el backup PRUEBAS de
- No analizamos la capacidad de
RESTORE
restaurar distintos elementos
RECURSOS
(tabla/filas) (Granularidad)
ESPACIO
FISICO
Backup Contínuo - Generalidades 1/2
• Existe en todas las bases de datos (con diferentes
nombres)
• Ventaja: Reduce al mínimo la Ventana de Pérdida,
con un buen costo beneficio.
• Consiste en resguardar toda la actividad
transaccional en LOGS (en postgres WAL)
• A medida que un LOG se llena el mismo motor de
base de datos lo backupea
Backup Contínuo - Generalidades 2/2
• Requiere un punto de inicio, es decir un
Backup Total inicial
• Al momento del restore, disponemos también
de muchos backups pequeños (los LOGs)
para restaurar en forma secuencial.
• El restore es una secuencia de varios
restores:
– Restore del BACKUP TOTAL inicial
– Múltiples restores de los LOGs (o WALs)
• Disponible en Postgres e Informix (y otros)
Métodos de Backup en Postgres
PG_DUMP
COPIA de FILE SYSTEM
BACKUP CONTINUO(PITR)
Granularidad
Cluster/BasedeDatos/Tabla
Cluster Completo
Cluster Completo
Ventana de
Perdida
Grande
Grande
Pequeña o Nula
Down Time
Puede hacerse
con Usuarios
Postgres debe
estar off-line
Puede hacerse
con Usuarios
Complejidad
Baja
Baja
Media
Formato del
Backup
Texto o Comprimido
Duración
depende el formato
Periodicidad
La frecuencia es importante
Es una copia exacta de la
imagen en el file system
rápido
La frecuencia es
importante
Formado por varios
componentes, de
diferente formato
rápido
La frecuencia tiene menos
importacia
Ejemplo de Restore sin Backup Continuo
pg_ctl stop
tar cf $PGDATA
Modificaciones a la BD
desde aplicaciones
Pilagá /Diaguita
/Mapuche /Guaraní
04:00 PM falla de un
disco, salida de servicio
de postgres
05:00 PM tar xf < mi_full_backup.tar
6:00 AM
Full
Backup
File
System
Datos recuperados hasta
las 06 AM (se perdieron
las modificaciones
realizadas en las últimas
10 horas)
(*) Dependiendo de la severidad de la falla, es posible que sean necesarias tareas previas al
restore. (Reinstalación de linux, postgres,)
Ejemplo de Restore sin Backup Continuo
04:00 PM falla de un disco,
postgres sale de servicio
Postgres backupea WAL
segments en forma continua
Full backup file
system (online)
6:00 AM
6:30AM
Backup
WAL AA
Backup
full file
system
05 PM Restore full backup
+WAL AA+WAL AB+WAL AC
Modificaciones a la BD desde
aplicaciones Pilaga /Diaguita
/Mapuche / Guaraní
1:16PM
Backup
WAL AB
3:38PM
Backup
WAL AC
Datos
recuperados
hasta las 3:38
PM
(*) Dependiendo de la severidad de la falla, es posible que sean necesarias tareas previas al
restore. (Reinstalación de Linux, de Postgres )
Segmentos WAL (1/3)
• Cada WAL tiene 16 Mb y es un archivo
• Se almacenan en $PGDATA/pg_xlog
• Cada vez que se llena un WAL, se crea el próximo. Sus nombres
son de la forma:
– 000000010000000000000001 al 000000010000000000000009
– 00000001000000000000000A al 00000001000000000000000Z
• Para backupear los WAL hay que modificar 2 parámetros
archive_mode = on
archive_command = 'cp %p /usr/local/carpetadebackupdewals/%f‘
– %p es el archivo con el path completo
– %f es solo el nombre del file
Segmentos WAL (2/3)
Qué Pasa cuando operamos normalmente con las BDs?
• Las transacciones se graban en los WAL segments, y los
van llenando.
• Cuando se llena un WAL Segment Postgres ejecuta el
comando del parámetro archive_command
• Este comando debería copiar el WAL recien completado a
una carpeta en un lugar seguro (disco remoto)
• Se borra el WAL Segment del directorio pg_xlog (en
realidad se lo renombra y se reutiliza el archivo para otro
WAL)
Segmentos WAL (3/3)
En algunos casos cuando Postgres necesita swichear al siguiente
WAL file renombra uno ya existente que esta backupeado y no tiene
transacciones abiertas.
Esto puede generar algo de confusión porque podemos ver que
el WAL 00000000AA fue modificado a las 10:22
y el
WAL 00000000AB fue modificado a las 10:18
En realidad el archivo WAL 00000000AB es el mismo archivo que antes se
llamaba 0000000012, el cual fue accedido por última vez a las 10:18, luego se
lo renombró a 00000000AB
Backup Total Inicial de Postgres
1. Desde psql ejecutar
# select pg_start_backup(’Full Backup - Testing’);
pg_start_backup() pg_start_backup crea un label, y lo graba en el WAL file.
0/6BA9328
Es opcional, pero se recomienda
2. Desde línea de comandos hacer un backup base.
tar -cvf /usr/local/mi_backup.tar $PGDATA
3. Desde psql ejecutar
# select pg_stop_backup();
0/6BA9384
Este es el Backup Total Inicial!!!
pg_stop_backup también crea un label y lo
graba en el WAL file.
Es opcional, pero se recomienda
Backup Total Inicial de Postgres
Todo Backup Inicial tiene un archivo en el pg_xlog con
extensión .backup que describe ese backup
Preparativos para restaurar un Backup
Continuo
1) Se supone que postgres está bajo (sino bajarlo)
2) Tres Elementos Necesarios
A) El backup Total Inicial (es lo principal, sin esto no hay restore posible)
B) El directorio con los WAL backupeados por Postgres (muy importantes)
C) El directorio pg_xlog (con los WAL aun sin backupear que estaban en pg_xlog al
momento de la caída. Contienen las últimas transacciones. Dependiendo del daño en disco puede
ser que se hayan perdido )
3) Para chequear podemos ver el archivo .backup del backup Inicial
que queremos restaurar, para determinar el primer WAL que
necesitamos. Ese WAL debe existir en el directorio de B)
4) Renombrar el pg_xlog actual a pg_xlog_recientes
5) Revisar si en pg_xlog_recientes existen WAL segments que no están
backupeados [son los de C)]. Backupearlos a mano si queremos
recuperarlos.
Restaurar un Backup Continuo y Todos
los segmentos WAL disponibles
6) Restaurar con un tar (o el comando que corresponda) el backup
base (no levantar postgres todavía)
7) Modificar el archivo recovery.conf (ver recovery.done)
8) Levantar Postgres. (cuando postgres levanta encuentra el
recovery.conf, y comienza a copiar los WAL y a aplicar las
transacciones en los WAL)
Postgres finalmente levanta cuando haya procesado TODOS los
segmentos WAL disponibles
Restaurar un Backup Continuo y los
WAL Segments con PITR
6) Restaurar con un tar (o el comando que corresponda) el backup
base (no levantar postgres todavía)
7) Modificar el archivo recovery.conf seteando el parámetro
recovery_target_time con la fecha y hora donde queremos parar de
restaurar
8) Levantar Postgres. (Idem al restore anterior, solo que procesa las
transacciones previas al recovery_target_time)
Como zafar si no hicimos Backup
PostgreSQL
Streaming Replication
Streaming Replication: Idea
• El restore de un Backup compuesto de muchos
WAL puede demorar tiempo.
• Algunas organizaciones no pueden tener su
base de datos fuera de línea por mucho tiempo.
• Backup Continuo es una solución al problema
de "Recuperación Ante Desastres"
• Backup Continuo NO es una solución al
problema de “Alta Disponibilidad”
Streaming Replication: Qué es ?
• Funcionalidad de PostgreSQL que permite
tener un servidor de base de datos espejado (o
stand by), que se actualiza permanentemente
con los cambios que recibe el servidor primario.
• Disponible a partir de la versión 9 de Postgres.
• Se puede combinar con otro feature (también
incluido en 9) llamado "Hot Stand By". El cual
permite usar el servidor espejado para hacer
lecturas.
Streaming Replication: Beneficios
• Alta Disponibilidad: Mediante una copia
completa de la base de producción lista para ser
usada en una emergencia. (En realidad tenemos
un servidor completo duplicado)
• Balanceo de Carga: Utilizando el servidor
espejado para aplicaciones Read Only
• Existen diferentes niveles de sincronismo
Nodo
Primario
Nodo Stand By
(ReadOnly)
Los NO de Streaming Replication
• Granularidad Unica: No se puede replicar
una tabla, esquema, o database. Solo el
Cluster completo.
• No soporta diferentes versiones de
Postgres.
• No soporta diferentes plataformas de S.O.
• No se puede tener Multi-master replication.
Basado en WALs
• Este tipo de replicación está basada en los
WAL.
• En el servidor primario cada modificación a los
datos (o DDL) se graba en los WAL.
• Los WAL son enviados y procesados en el
servidor Stand By para generar una imagen
idéntica al primario.
Niveles de Sincronismo
• Log Shipping Standby (file based)
– Se envía el archivo WAL completo al Stand By
– El Stand By tiene una demora de “1 WAL”
– Claramente es Asíncrono
• Streaming Replication
– Se envían los registros de la WAL luego del
commit
– El Stand By esta menos retrasado.
– Es posible monitorear el “delay”
Streaming Replication: Gráfico
• Configuración
– Se configura como Log Shippping y se agrega
el parámetro primary_conninfo en recovery.conf
– Puede ser Sincrónico o Asincrónico.
• Asincrónico: Es el default ( si cae el primario podría
haber pequeñas pérdidas de datos. Transacciones comiteadas
que aun no fueron replicadas)
• Sincrónico: Sin pérdida de transacciones pero el
Commit es más lento (cada commit espera recibir la
confirmación de que el commit ha sido recibido y escrito al Log
de transacciones en disco en el postgres primario y el standby)
Cómo lo configuramos ?
• Preparación previa de algunos archivos de
configuración
• Backup en el cluster primario y restore en el
servidor espejado
• Levantar postgres en el servidor espejado
• Testear que todo este funcionando
Configuración previa Postgres Primario
Activamos el backup automático de WAL
• archive_mode: Activa el archivado de WAL en primario.
• archive_command: Indica el comando de copia de WAL
Configuración previa Postgres Primario
• max_wal_senders: Con este parámetro definimos el número máximo
de conexiones que se pueden realizar desde servidores stand by al
servidor primario via SR (1 por servidor stand by)
• wal_keep_segments: Este parámetro define el número máximo de
ficheros WAL que mantendremos sin reciclar en el servidor primario en
el caso que SR se retrase en la replicación de datos. Si utilizamos
además de SR, transferencia de ficheros WAL, este parámetro no es
tan importante de configurar.
• listen_addresses: Con este parámetro definimos la IP por la que
podremos acceder via TCP/IP a postgreSQL.
• wal_level: Este parámetro define cuanta información se grabará en los
ficheros WAL generados. Se pueden utilizar tres valores, minimal,
archive y hot_standby. En nuestro caso utilizamos el valor hot_standby,
porque vamos a utilizar esta funcionalidad.
Configuración previa Postgres Stand By
• listen_addresses: Con este parámetro definimos la IP por la que
podremos acceder via TCP/IP a postgreSQL.
• hot_standby: Para definir que este servidor esclavo se podrá utilizar
para realizar consultas de solo lectura.
Configuración previa SRV Stand By
ARCHIVO recovery.conf
• standby_mode: (on) Este parámetro define que el servidor no saldrá
del modo de recuperación y continuará probando la restauración
continua de información WAL
• primary_conninfo: Este parámetro define el servidor maestro usado
por SR para leer los registros WAL del primario (streaming replication)
• trigger_file: Con este parámetro se define un fichero que en caso de
crearse/existir sacará al servidor standby del modo "hot standby" y de
recuperación continua.
• restore_command: Con este parámetro definimos el comando a
utilizar, si es necesario, para restaurar los ficheros WAL que fueron
backupeados desde el servidor primario.
Failover Activar el Stand By como Primario
• Postgres NO provee ningún mecanismo para
detectar la caida del primario (hearbeat)
• Decisión de hacer failover:
– El DBA
– Algún software externo a postgres
– Cuidado con tener 2 primarios
• Activación del Failover:
– pg_ctl promote
– trigger_file setting en recovery.conf
Test
PostgreSQL
Nuevas Funcionalidades
9.2 y 9.3
Nuevas Funcionalidades 9.2 / 9.3
• Vistas Materializadas (materialized views) 9.3
(1)
create view test1 as select 1 as a where pg_sleep(5) is not null;
CREATE VIEW
$ \timing
Timing is on.
$ select * from test1;
a
--1
(1 row)
Time: 5008.621 ms
a
--1
(1 row)
Time: 5001.657 ms
a
--1
(1 row)
Time: 5001.519 ms
(2)
create materialized view test2 as
select 1 as a where pg_sleep(5) is not null;
SELECT 1
$ \timing
Timing is on.
a
--1
(1 row)
Time: 8.060 ms
a
--1
(1 row)
a
--1
(1 row)
Time: 0.311 ms
Time: 0.263 ms
REFRESH MATERIALIZED VIEW test2;
REFRESH MATERIALIZED VIEW
Time: 5037.111 ms
(3)
• Vistas actualizables 9.3
(1)
CREATE VIEW cliente_v AS SELECT * FROM cliente;
SELECT * FROM cliente_v;
1;"Tita"
2;"Antonia"
3;"Ramiro"
INSERT INTO cliente_v VALUES (4,’Luana');
SELECT * FROM cliente_v;
1;"Tita"
2;"Antonia"
3;"Ramiro"
4;"Luana"
• Vistas actualizables 9.3
(2)
Los peros:
- Se permiten INSERT, UPDATE y DELETE para ser utilizado en la vista de la
misma forma que en una taba normal.
- Solo sirve para vistas simples.
- Debe tener UNA entrada en su lista FROM (que debe ser una tabla u otra vista actualizable)
- La definición de vista no debe contener DISTINCT, GROUP BY, HAVING,
LIMIT, OFFSET.
- La definición de vista no debe contener operaciones de conjuntos (UNION,
INTERSECT o EXCEPT).
- Todas las columnas del select deben ser simples referencias a columnas. No
pueden ser expresiones literales o funciones.
• Checksum 9.3
(1)
Sumas de verificación de páginas de datos
CRC-16 algorithm for the checksum calculation.
- El parametro data_checksums es de solo lectura. Solo puede setear con el parametro
initdb. (no esta presente en el postgresql.conf).
- Verificación del estado del parametro:
postgres=# SHOW data_checksums;
data_checksums
on
(1 row)
postgres=# select * from corruption_test;
WARNING: page verification failed, calculated checksum 63023 but
expected 48009
ERROR:
invalid page in block 0 of relation base/12896/16409
• Conectores de datos Foraneos Modificables 9.3
(1)
CREATE TABLE cliente (id integer, nombre text);
INSERT INTO cliente VALUES
(1,'Tita'),(2,'Antonia'),(3,'Ramiro'),(4,'Delfina');
CREATE EXTENSION postgres_fdw;
CREATE SERVER source FOREIGN DATA WRAPPER postgres_fdw OPTIONS (host
'localhost', dbname 'prueba', port '5433');
CREATE USER MAPPING FOR postgres SERVER source OPTIONS ( user
'postgres', password 'postgres');
CREATE FOREIGN TABLE cliente_externo (
id serial,
nombre text
) SERVER source
options ( table_name 'cliente' );
SELECT * FROM cliente;
1;"Tita"
2;"Antonia"
3;"Ramiro"
4;"Delfina"
(2)
SELECT * FROM cliente_externo;
1;"Tita"
2;"Antonia"
3;"Ramiro"
4;"Delfina"
INSERT INTO cliente VALUES (5,'Francisca');
1;"Tita"
2;"Antonia"
3;"Ramiro"
4;"Delfina"
5;"Francisca"
1;"Tita"
2;"Antonia"
3;"Ramiro"
4;"Delfina"
5;"Francisca"
(3)
INSERT INTO cliente_externo VALUES (6,'Luana');
1;"Tita"
2;"Antonia"
3;"Ramiro"
4;"Delfina"
5;"Francisca"
6;"Luana"
1;"Tita"
2;"Antonia"
3;"Ramiro"
4;"Delfina"
5;"Francisca"
6;"Luana"
Nota: El driver debe soportar la funcionalidad de modificación
• Pg_dump paralelo
9.3
(1)
Desde 9.1 existe pg_restore –j
realiza el respaldo de tablas en paralelo.
A partir de 9.3 pg_dump –j xx
xx: número de procesos
+ Reduce el tiempo de backup
- Incrementa la carga en el servidor
- Se puede utilizar solo con pg_restore –Fd (directory)
• Triggers disparados por eventos 9.3
(1)
CREATE EVENT TRIGGER name
ON event
[ WHEN filter_variable IN (filter_value [, ... ]) [ AND ... ] ]
EXECUTE PROCEDURE function_name()
event: ddl_command_start,ddl_command_end and sql_drop
filter_variable: Nombre de la variable que se va a utilizar en el
filtro. Actualmente la unica disponible es TAG.
filter_value: Valor (o lista de valores) asociada al filtro
(2)
CREATE OR REPLACE FUNCTION abort_any_command() RETURNS event_trigger
LANGUAGE plpgsql AS $$
BEGIN
RAISE EXCEPTION 'command % is disabled', tg_tag;
END;
$$;
CREATE EVENT TRIGGER abort_ddl ON ddl_command_start
EXECUTE PROCEDURE abort_any_command();
CREATE TABLE a (id integer);
ERROR:
command CREATE TABLE is disabled
********** Error **********
ERROR: command CREATE TABLE is disabled
SQL state: P0001
(3)
ALTER EVENT TRIGGER abort_ddl disable;
CREATE EVENT TRIGGER abort_ddl_2 ON ddl_command_start
WHEN tag IN ('DROP TABLE')
EXECUTE PROCEDURE abort_any_command();
CREATE TABLE a (id integer); ok
DROP TABLE a;
ERROR:
command DROP TABLE is disabled
********** Error **********
ERROR: command DROP TABLE is disabled
SQL state: P0001
• IF EXISTS
9.2
(3)
ALTER TABLE zzz ADD COLUMN t1 integer;
ERROR:
relation "zzz" does not exist
ALTER TABLE IF EXISTS t1 ADD COLUMN q integer;
NOTICE:
relation "zzz" does not exist, skipping
object
create
alter
drop
index
not supported
works
works
table
works
works
works
sequence
not supported
works
works
view
not supported
works
works
function
not supported
not supported
works
• INDEX-ONLY SCAN
9.2
(1)
Cuando un índice btree contiene todas las columnas que
se requieren en la consulta, postgres evita irlas a
buscar al heap.
• JSON
9.2 / 9.3
(1)
Se agregaron nuevas funciones para parsear datos que
vienen en formato JSON
• CASCADING STREAMING REPLICATION
9.2
(1)
Agrega la posibilidad de replicación en cascada (para
streaming log replication).
Los servidores esclavos (Standby servers), ahora pueden
encargarse de enviar la WAL a otro servidor.
Se usa para reducir el numero de
conexiones directas entre el
master y los esclavos.
Foro de Postgres
http://comunidad.siu.edu.ar/foro/index.php?board=17.0
PostgreSQL
¡MUCHAS GRACIAS!
¿consultas?

PostgreSQL

Transcripción

Documentos relacionados

curso backup retrospect - cev empresas

Guía de uso “Cómo realizar la carga inicial de datos en