Ejercicio

1. ALTA DISPONIBILIDAD Y BALANCEO DE CARGA
Los servidores de bases de datos pueden trabajar en conjunto para permitir a un segundo servidor
pasar a un plano principal si el primero cae (alta disponibilidad) , o permitir a varias computadoras
servir la misma información (balance de carga). Idealmente, los servidores de bases de datos
podrían trabajar conjuntamente. Los servidores que ofrecen paginas web estáticas pueden ser
combinadas fácilmente mediante el balanceo de carga para múltiples peticiones. De hecho,
servidores con bases de datos de solo lectura pueden ser combinadas de una forma relativamente
fácil. Desafortunadamente, la mayoría de los servidores de bases de datos tienen muchas peticiones
mezcladas de lectura/escritura, y esto es mucho más difícil de combinar. Esto es así debido a que
para implementar servidores de solo lectura, solamente se necesita colocar la información una vez
en el/los servidor/es replicados, y escribir en el principal únicamente, que será el que propague a
todos los servidores replicados.
El problema de la sincronización es la principal dificultad para trabajar con los servidores
conjuntamente. Esto es debido a que no hay una única solución que elimine el impacto del
problema de la sincronización para cada caso concreto. Cada problema se resuelve de diferente
forma, y minimiza el impacto para una carga específica de trabajo.
Algunas soluciones tratan la sincronización permitiendo que solo un servidor sea el que modifique
los datos. Los servidores que pueden modificar los servidores llamados de escritura/lectura,
maestros o primarios. Los servidores que siguen los cambios en el maestro son llamados “standby”
o servidores esclavos. Un servidor standby que no puede ser conectado hasta que sea promovido
por un servidor maestro se denomina “warm standby server”, y uno que puede aceptar conexiones y
peticiones de solo lectura es denominado “hot standby server”.
Algunas soluciones son síncronas, que quiere decir que una transacción de modificación de datos no
es considerada “committed” o consignada, hasta que todos los servidores han consignado la
transacción. Esto garantiza que un fallo no hará perder ningún dato y que todo el balanceo de carga
de los servidores devolverá resultados consistentes sin importar en qué servidor se realiza una
petición. En contraste, las soluciones asíncronas permiten algo de retraso entre el tiempo de un
“commit” o consignación y su propagación al resto de servidores, abriendo la posibilidad the
algunas transacciones podrían ser perdidas en el cambio a un servidor de copia de seguridad, y que
los servidores de carga balanceada podrían devolver resultados ligeramente diferentes. La
comunicación asíncrona es utilizada cuando la síncrona es muy lenta.
En este caso la replicación propuesta es una Replicación “Master-Standby”

2. LOG-SHIPPING
Log-Shipping se puede describir como el traspaso de registros WAL de una base de datos a otra.
PostgreSQL implementa este trasvase de registros o log-shipping mediante la transferencia de UN
archivo WAL (o segmento WAL). Los archivos WAL (de 16MB) pueden ser trasvasados fácilmente
y con coste bajo a cualquier distancia. El ancho de banda requerido para esta técnica varía de
acuerdo con la tasa de transferencia del servidor primario.
Hay que tener en cuenta que el “log-shipping” es asíncrono, ya que los registros WAL son
trasvasados tras la conclusión de una transacción. Como resultado hay una ventana de pérdida de
datos si el servidor primario sufre un fallo, y las transacciones no trasvasadas se darán por perdidas.
El tamaño de la ventana de pérdida de datos puede ser limitada mediante el uso del parámetro
“archive_timeout”, el cual debe ser configurado cuanto más bajo posible mejor (unos pocos
segundos). Sin embargo con una configuración baja de segundos incrementaremos sustancialmente
el ancho de banda dedicado al log-shipping. La replicación bajo streaming nos permite una ventana
de pérdida mucho menor.
El rendimiento de recuperación es suficientemente bueno que el el servidor replicado (que
denominamos standby) tendrá plena disponibilidad en breves momentos tras ser activado.
Como resultado, tendremos una configuración que ofrece alta disponibilidad denominada “warm
standby”. Un servidor standby puede ser usado para consultas de solo lectura, siendo este caso
denominado servidor “Hot Standby”.

3. MODO “SERVIDOR STANDBY”
En el modo Standby (o en espera), el servidor replicado aplica los archivos WAL recibidos por el
servidor maestro. El servidor en standby puede leer información WAL bien desde un archivo o
directamente del servidor maestro bajo una conexión TCP (streaming replication). El servidor
standby también intentará restaurar cualquier archivo WAL encontrado en el directorio pg_xlog del
cluster standby. Hecho que ocurre normalmente después de reiniciar un servidor, cuando el servidor
standby procesa otra vez el archivo WAL que fue enviado por el maestro con anterioridad, pero se
puede hacer también de forma manual copiando los archivos al directorio pg_xlog en cualquier
momento para volverlo a procesar.
Al inicio, el servidor standby comienza por las restauración de todos los archivos WAL disponibles
en la dirección indicada, llamando al restore_command. Si una vez alcanzado el final de la
información WAL disponible, y el restore_command falla, se puede intentar restaurar cualquier
archivo WAL disponible en el directorio pg_xlog. Si falla, y la replicación por streaming ha sido
configurada, el servidor en standby intentará conectarse con el servidor primario y empezar el
streaming WAL desde el último registro válido encontrado en el directorio o pg_xlog. Si esto falla o
el streaming no está configurado, o si la conexión permanece desconectada, el servidor standby
regresará al punto uno, e intentará restaurar el directorio otra vez. Este bucle de reintentos del
directorio (pg_xlog) y la replicación vía streaming continuará hasta que el servidor sea parado o
caiga disparado por un trigger.
PREPARANDO EL SERVIDOR MAESTRO PARA SERVIDORES STANDBY
Configurar el archivo continuo en el servidor primario hacia un directorio accesible para el servidor
en standby se realiza de la siguiente manera.
Un servicio postgresSQL en funcionamiento produce una secuencia indefinida de registros.
El sistema físicamente los divide en segmentos WAL, los cuales adoptan un tamaño de
16megas (aunque el segmento puede ser modificado en la compilación de postgres). Los
segmentos tienen nombres numéricos que reflejan su posición en la secuencia abstracta
WAL. Cuando no se está utilizando el archivo WAL, el sistema normalmente crea unos
pocos segmentos y entonces recicla los anteriores mediante el renombramiento a un numero
más alto. Es asumido que los archivos contenidos preceden a un checkpoint anterior al
último o no son de interés y por tanto podrán ser reciclados.
1. Activar el archivo WAL
Para activar el archivo WAL, hay que configurar el parámetro “wal_level” a archive (o
host_standby), el modo archive a on, y especificar el comando shell a utilizar en el
parámetro “archive_command”. En la practica estas configuraciones siempre están en el
archivo postgresql.conf. Dentro del parámetro “archive_command”, %p es reemplazado por
el nombre de la ruta donde se van a guardar los archivos WAL, mientras que %f es
reemplazado solamente por el nombre de archivo en sí. (el nombre de la ruta es relativa al
actual directorio de trabajo, por ejemple el directorio del cluster).
archive_command = 'test ! -f /mnt/server/archivedir/%f && cp %p
/mnt/server/archivedir/%f' # Unix
archive_command = 'copy "%p" "C:serverarchivedir%f"' # Windows
Si ejecutasemos el primer comando los archivos se guardaría de esta manera:
test ! -f /mnt/server/archivedir/00000001000000A900000065 && cp
pg_xlog/00000001000000A900000065

4. /mnt/server/archivedir/00000001000000A900000065
El comando deberá ser ejecutado por el propietario que será el mismo usuario sobre el que el
servidor PostgreSQL está corriendo. Como recomendación sería prudente cambiar los
permisos del directorio para que no todos pudieran acceder a éste ya que contiene toda la
información de la base de datos.
Si el comando devuelve cero en el estatus, todo habrá ido correctamente y postgres asumirá
que los archivos se han guardado correctamente.
Si quisiésemos una replicación streaming, configuraríamos la autenticación en el servidor
primario para permitir la replicación desde los servidores en standby; es decir, crearíamos
un rol y lo proveeríamos de una entrada en pg_hba.conf con el campo de la base de datos a
replicar. Además asegurarse que el parámetro “max_wal_senders” está configurado lo
suficientemente grande para el servidor primario.
2. Realizar una copia de seguridad base para arrancar el servidor standby
El procedimiento para realizar un backup base es relativamente simple.
1- Asegurarse que el archivo WAL está activo y trabajando.
2- Conectarse a la base de datos como superusuario y utilizar el comando:
SELECT pg_start_backup ('label, true');
donde label es cualquier cadena que querramos para identificar la operación.
pg_start_backup creará un archivo de backup en el directorio del cluster con la información .
3. Ejecutar el backup, utilizando una herramienta convieniente como tar o cpio (no
pg_dump ni pg_dumpall).
4. Conectar otra vez con la base de datos como superusuario y ejecutar el comando:
SELECT pg_stop_backup();
Esto termina el modo backup y ejecuta el cambio al siguiente segmento WAL.
5. Una vez que los segmentos WAL estén archivos, estará ok.
Si quisiésemos utilizar la replicación streaming, configurar la autenticación en el servidor primario
para permitir conexiones replicadas desde el servidor standby; esto es, crear un rol y prever una
apropiada entrada o entradas en pg_hba_conf con el campo de la base de datos configurada para la
replicación.

5. Bases de dades PostgreSQL. REPLICACIÓ.
Instruccions
Anomena i desa aquest arxiu amb aquesta estructura de nom:
CognomNom_ASIXIAW_UF3_P6.PDF
Exemple: FernàndezXavi_ASIXIAW_UF3_P6.PDF
Has de lliurar el document amb la pràctica realitzada al moodle dins de la data prevista.
Als documents amb un nom diferent al proposat se'ls descomptarà un 1 punt de la nota. PDF
Activitats
En aquesta pràctica realitzarem una replicació entre un servidor mestre i un servidor esclau.
L'escenari és el següent: Dos màquines virtuals amb SO Ms Windows de 32bits. Cal tindre en
compte que les versions han de ser idèntiques. Farem ús del passos descrits en el pdf de la pre-
sentació.
Per dur a terme aquesta tasca necessitarem:
- Dos màquines virtuals Windows 7, el SGBD PostgresSQL.
Activitats a realitzar en la pràctica:
- Crea un servidor mestre i altre d'esclau amb PostgreSQL instal·lat.
- Crea una base de dades exemple al servidor mestre amb alguna taula i dades.
- Fes una còpia inicial i transfereix el directori de dades com diu el pdf.
- Realitza els passos necessaris per tal d'activar la replicació.
- Resultat: PostgreSQL replicant-se en el servidor esclau amb accés en mode lectura.
Documentació que heu de lliurar:
1. Documenta solament amb imatges.
En aquesta ocasió, una vegada finalitzada la replicació, hauràs de fer una demostració al
professor del funcionament de l'activitat.

6. ACTIVIDAD
1. Para empezar tendremos que tener los Servidores con una IP fija y en la misma red ya que la
transmisión de datos va a ser vía TCP y las direcciones han de conocerse.
Para el maestro:
Para el servidor:

7. CONFIGURANDO EL SERVIDOR MAESTRO
Empezamos!!
Vamos a C:Program FilesPostgreSQL9.5data
Vamos a la zona de conexiones y autenticación y decimos al maestro que escuche las peticiones de
cualquier máquina de la red. NOTA (en este caso podríamos restringirlo a la IP del Servidor Stanby
ya que solo tengo uno)
Vamos a la zona de configuración WAL (Write Ahead Log)
Activamos el archivamiento y el comando de archivo que copie los WAL de postgres a un directorio
de la máquina.

8. Creamos la carpeta en el c:archivos_WAL
Vamos a la zona de configuración de REPLICACIÓN
CAMBIAMOS DE ARCHIVO DE CONFIGURACIÓN HBA
C:Program FilesPostgreSQL9.5datapg_hba.conf
Permitimos conexiones desde otros equipos para la replicación.

9. REALIZACIÓN DE UNA COPIA BASE SERVIDOR MAESTRO
Empezamos la copia base
Copiamos el directorio data
Paramos la copia base
CONFIGURANDO EL SERVIDOR ESCLAVO
Activamos el standby

10. Creamos un archivo denominado recovery.conf
Reemplazamos los archivos del data que hay en el server con el maestro, exceptuando
postgresql.conf, el .auto, hba.conf, y postmaster.pid.
Reiniciamos el servicio.