1.6 Planning
2.2.2 Sophisticated Virtual Network Embedding Algorithms
2.2.2.2 Dependability
Una vez creada la partición cuyo contenido va a ser replicado ya podemos comenzar a configurar el servicio. Toda la configuración de DRBD se lleva a cabo en un único archivo de configuración, drbd.conf el cual podemos encontrar en el tar.gz, en el directorio scripts además perfectamente documentado.
El archivo drbd.conf tiene que encontrarse en el directorio etc. Un ejemplo básico de este archivo de configuración es el Código 4-16. ha.cf
Código 4-16. ha.cf
resource nombre_recurso { # Por ejemplo: resource r0 common {
protocol C; }
on nombre_del_nodo_1 {
device /dev/drbd0; #Path de la unidad virtual /dev/drbdx disk /dev/sdb1; #Path de la partición a usar para replicación address direcciónIP_nodo_1:puerto_para_replicar;
meta-disk internal; }
on nombre_del_nodo_2 {
device /dev/drbd0; #Path de la unidad virtual /dev/drbdx disk /dev/sdb1; #Path de la partición a usar para replicación address direcciónIP_nodo_2:puerto_para_replicar;
meta-disk internal; }
}
Nota: este archivo de configuración debe ser igual en ambos nodos
El archivo de configuración que se acaba de mostrar es un archivo de configuración para una configuración básica de DRBD.
La replicación del recurso se va a realizar de una manera totalmente síncrona ya que se ha seleccionado como modo de replicación el protocolo C.
Nota: el protocolo C es un protocolo de replicación síncrono. Las operaciones de escritura
locales en el nodo primario son consideradas “completas” solo después de que ambos nodos realicen la escritura en sus discos correspondientes, es decir, se repliquen. Por tanto la pérdida de un nodo garantiza que los datos no se perderán. Una posibilidad en la que se perderían los datos inevitablemente es si ambos nodos fallan en el mismo instante, caso bastante improbable
En este ejemplo básico de configuración se define un cluster de replicación formado por dos nodos, nodo_1 y nodo_2. En el bloque definido para cada uno de ellos se indica el camino o
path de la unidad virtual, el camino o path de la partición física a usar que va a contener la
redundancia de datos, la dirección IP del propio nodo junto con el puerto que va a usar para sincronizarse con el otro nodo y un disco de metadatos interno. El espacio para metadatos es utilizado por DRBD para almacenar el tamaño de la partición DRBD, identificadores, los bloques de disco que están sincronizados, obsoletos o son inconsistentes, etc. En definitiva en él se almacena la información que DRBD necesita para funcionar.
Ahora es necesario, en ambos nodos, crear el espacio para metadatos y la unidad virtual a la que hemos hecho referencia en el archivo de configuración drbd.conf.
drbdadm create-md nombre_recurso drbdadm attach nombre_recurso
La salida esperada de create-md es: drbdadm create-md resource v08 Magic number not found Writing meta data...
initialising activity log NOT initialized bitmap
New drbd meta data block sucessfully created. success
Sin embargo, al ejecutar attach podemos obtener un error como el siguiente:
Figura 4-9. Un posible error durante la configuración de DRBD
Tanto si la salida de create-md no es la esperada como si obtenemos un error al ejecutar
attach, el motivo es que el servicio drbd esta arrancado y no permite ni crear los metadatos ni
crear una unidad virtual en este estado por lo que, previamente, hay que parar el servicio
/etc/init.d/drbd stop.
Si por el contrario no se muestra ningún error, es entonces el momento de arrancar drbd en ambos nodos.
/etc/init.d/drbd start
Una vez que DRBD se encuentra arrancado en ambos nodos se ha de proceder a establecer la comunicación entre los dos nodos para que pueda dar comienzo la sincronización inicial. Para conectarlos hay que ejecutar el siguiente comando:
drbdadm connect nombre_recurso
Es posible ver el estado de la sincronización de las particiones de disco mediante el comando:
cat /proc/drbd
Por último, y una vez que se ha determinado la partición virtual en ambos nodos y ambos nodos se ha conectado entre sí, es necesario, realizar la sincronización inicial entre los dispositivos de bloque de datos creados. Este paso solo ha de realizarse en un nodo, y solo en el nodo cuyos datos queremos conservar y replicar. Es muy importante prestar especial atención a este punto para no realizar la sincronización inicial en la dirección equivocada. Para ello, ejecutar en el nodo cuyos datos queremos conservar y replicar, el siguiente comando: drbdadm -- --overwrite-data-of-peer primary nombre_recurso
Los datos comenzarán a sincronizarse. El tiempo que dura el proceso dependerá de la velocidad de la red, del tamaño de la partición a replicar así como de la velocidad de transferencia indicada en el archivo de configuración de DRBD. Se puede consultar el estado de la replicación mediante el comando cat /proc/drbd.
Una vez finalizada la sincronización podemos comprobar mediante el comando cat
/proc/drbd si DRBD ya se encuentra preparado. Para ello cs ha de ser Connected, indicando que
ambos nodos están conectados, ld ha de ser UpToDate indicando que los datos se encuentran sincronizados y actualizados y st ha de ser Primary/Secondary en un nodo y Secondary/Primary en el otro quedando así perfectamente definido el rol DRBD de cada uno de los nodos. Finalmente DRBD está operativo.
La idea ahora es la de crear un sistema de ficheros en la partición virtual, montarla para poder hacer uso de ella como si se tratara de una partición normal. Por tanto, creamos el sistema de ficheros:
mke2fs –j /dev/drbd0
Y montamos la partición virtual para guardar aquellos datos que queremos replicar en el directorio /media/replica:
mkdir /media/replica mount /dev/drbd0 /replica
Para realizar la copia de datos en la partición virtual: se copia en ella los directorios y/o archivos que deseamos, manteniendo la estructura original, y se sustituyen estos archivos copiados por un enlace simbólico que haga referencia a estos archivos situados ahora en la partición virtual.
5
5
MMyySSQQLLRReepplliiccaattiioonn
El software MySQL proporciona un servidor de base de datos SQL muy rápido, multiusuario y robusto. El servidor MySQL está diseñado para entornos de producción críticos, con alta carga de trabajo así como para integrarse en software para ser distribuido. MySQL es una marca registrada de MySQL AB y se ha convertido en unas de las bases de datos de código abierto más populares siendo uno de los motivos que los usuarios tienen la opción de poder elegir entre usar el software MySQL como un producto Open Source bajo los términos de la licencia GNU General Public License o pueden adquirir una licencia comercial estándar de
MySQL AB.
Son varias las versiones existentes de MySQL pero en este punto se va a tratar concretamente MySQL 5.0.
Figura 4-10. Logotipo MySQL
Una de las características que incluye MySQL 5 es la de soporte de replicación, una replicación asíncrona unidireccional donde un servidor actúa como maestro y uno o más actúan como esclavos. El servidor maestro escribe las actualizaciones que se llevan a cabo en él, en el fichero de log binario, y mantiene un índice de los ficheros para rastrear las rotaciones de logs. Estos logs sirven como registros de actualizaciones para enviar a los servidores esclavos. Cuando un esclavo se conecta al maestro, el esclavo informa al maestro de la posición hasta la que ha leído los logs en la última actualización satisfactoria. El esclavo recibe cualquier actualización que ha tenido lugar desde entonces, y se bloquea y espera para recibir futuras actualizaciones enviadas por el master.
Figura 4-11. Replicación MySQL
Una característica muy importante de la replicación es la replicación en cadena, donde un servidor esclavo puede ser maestro para otro servidor esclavo como se muestra en la
figura 4-11 Replicación MySQL.
Hay que tener en cuenta que cuando se usa replicación, todas las actualizaciones de las tablas que se realizan en el servidor maestro se replican hacia los esclavos, por lo que hay que ser cuidadoso para evitar conflictos entre actualizaciones que hacen los usuarios en las tablas del maestro y las actualizaciones que se realizan en las tablas de los esclavos.
Esta replicación unidireccional tiene beneficios para la robustez, velocidad, y administración del sistema:
Robustez. Se incrementa con un escenario maestro/esclavo. En caso de problemas
con el maestro, puede cambiar al esclavo como copia de seguridad.
Velocidad. Puede conseguirse un mejor tiempo de respuesta dividiendo la carga de
consultas a procesar entre los servidores maestros y esclavo. Se puede enviar consultas SELECT al esclavo para reducir la carga en el maestro. Sin embargo, las sentencias que modifican datos deben enviarse siempre al maestro, de forma que el maestro y el esclavo no pierdan la sincronización. Esta estrategia de balanceo de carga es efectiva si dominan consultas que no actualizan datos frente a las que actualizan.
Administración del sistema. Otro beneficio de usar replicación es que se pueden
realizar copias de seguridad usando un servidor esclavo sin molestar al maestro. El maestro continúa procesando actualizaciones mientras se realiza la copia de seguridad.
5.1 Conceptos fundamentales
Antes de comenzar con la configuración de la replicación MySQL es necesario conocer como se lleva ésta a cabo, lo que obliga a conocer una serie de ficheros de texto en los cuales se indican los cambios que se han producido en el maestro, las actualizaciones llevadas a cabo por el esclavo, etc. A continuación se muestran un listado donde se indican los ficheros que intervienen en el proceso de replicación.
Log Binario
El registro binario contiene toda la información referente a actualizaciones, en un formato más eficiente y de una manera que es segura para las transacciones.
El registro binario contiene todas las sentencias que han actualizado datos o podrían haberlo hecho (por ejemplo, un DELETE que no encontró filas concordantes). Las sentencias se almacenan en forma de “eventos” que describen las modificaciones.
El registro binario también contiene información sobre cuánto ha tardado cada sentencia que actualizó la base de datos. No contiene sentencias que no hayan modificado datos, sin embargo, si se desea registrar todas las sentencias (por ejemplo, para identificar una sentencia problemática), esto es posible.
El propósito principal del registro binario es el de actualizar la base de datos durante una operación de recuperación tan pronto como sea posible, ya que el registro binario contiene todas las actualizaciones hechas tras la copia de seguridad. Otro de los propósitos es el de utilizarse como recordatorio de las sentencias llevadas a cabo en los servidores maestros que deben ser enviadas a los servidores esclavos.
Cuando MySQL se ha iniciado con la opción --log-bin[=file_name] mysqld escribe un archivo de registro que contiene todos los comandos SQL que actualizan datos. Si no se da ningún valor para file_name, el valor por defecto es el nombre de la máquina host seguido por
datos de datos MySQL. No es recomendable no dar ningún valor para el nombre de log-bin, ya que si el nombre de la máquina es modificado en un futuro, la replicación no funcionará.
mysqld agrega una extensión numérica al nombre del registro binario. Este número
se incrementa cada vez que se inicia el servidor o se vuelcan los registros. También se crea un nuevo registro binario cuando el actual llega al tamaño especificado en max_binlog_size. Un registro binario puede llegar a ser más grande de max_binlog_size si está utilizando transacciones grandes ya que una transacción se escribe en el registro de una sola pieza, no partiéndose nunca entre diferentes registros.
Log Binario Index
Mantiene un índice sobre cuáles y cuántos archivos de registro binario diferentes han sido utilizados. Por defecto éste tiene el mismo nombre que el archivo de registro binario, con la extensión .index. Puede cambiar el nombre del archivo de índice con la opción --log-bin-
index[=file_name]. No debería editar este archivo manualmente mientras mysqld se está
ejecutando ya que podría confundir a mysqld.
Relay Log
El esclavo lee el log binario del maestro y las actualizaciones realizadas en éste, las copia en ficheros locales, llamados logs retardados o relay log, en el directorio de datos del esclavo. Posteriormente el esclavo lee los logs retardados y ejecutar las actualizaciones que contiene.
Por defecto los relay log se nombran usando nombres de ficheros de la forma
host_name-relay-bin.nnnnnn, donde host_name es el nombre del servidor esclavo y nnnnnn es
un número de secuencia. Los ficheros de logs retardados sucesivos en MySQL 5.0 se crean usando números de secuencia sucesivos, comenzando a partir de 000001. Por defecto, estos ficheros se crean en el directorio de datos del esclavo cuyo nombre puede cambiarse con las opciones de servidor --relay-log.
Los logs retardados tienen el mismo formato que los logs binarios. Un log retardado se borra automáticamente por el flujo SQL en cuanto ha ejecutado todos sus eventos y no los necesita más.
Relay Log Index
El esclavo guarda los logs retardados en uso en este fichero índice. El nombre del índice del log retardado por defecto es host_name-relay-bin.index. Por defecto, este fichero se crea en el directorio de datos del esclavo cuyo nombre puede cambiarse con las opciones de servidor --relay-log-index .
master.info & relay-log.info
Un servidor esclavo de replicación crea dos pequeños ficheros adicionales en el directorio de datos. Estos ficheros de estado se llaman master.info y relay-log.info por defecto. Contienen información como la mostrada en la salida del comando SHOW SLAVE STATUS. Como ficheros escritos en disco que son sobreviven a una parada del servidor esclavo, de tal manera que la siguiente vez que arranque el servidor esclavo, leerá estos ficheros para
determinar hasta dónde ha procesado los logs binarios del maestro y sus propios logs retardados.
Mediante todos estos archivos, los datos relacionados con el proceso de replicación se hacen persistentes, por lo que ante la pérdida de comunicación entre los nodos o fallo de algunos de ellos, la replicación continuará automáticamente una vez solventados los problemas mencionados.