MySQL - High Availability - Load Balacing - Cluster

Base de datos MySQL
September 25, 2011

domingo 25 de septiembre de 11

Resumen

• Replicación en MySQL
– Introducción
– Tipos de nodos
– Tipos de arquitecturas
– Limitaciones
– Software de terceros
– Resumen

• MySQL Cluster
– Introducción
– Tipos de nodos
– Configuración
– Backup
– Restore

Dpto. Soporte SSAA -2- September 25, 2011


Replicación MySQL

Replicación MySQL



Replicación – Introducción

• Nodo Master
– Sirve para escrituras y lecturas
– Guarda los cambios en un log binario
– Almacena la posición y el fichero en el que se encuentra el log

• Nodo Slave
– Sirve para lecturas
– Puedes escribir, pero rompes la replicación
– Se suele usar para lanzar backups
– Puede tener engines diferentes al master



Replicación – Master Slave
Maestro-Esclavo

● Un maestro, múltiples esclavos.
● En el maestro se escribe, en el esclavo se lee.



Replicación – Introducción

• La replicación se basa en los logs binarios
– Un log binario guarda todas las modificaciones que se hacen a la base de datos
– El nodo maestro guarda las DDL (alter, create table, create index) y DML (insert, update,
delete, etc.)
– El nodo esclavo se conecta al de escritura para leer dicho log binario y reaplicar los
cambios

• En el master se suele logear todo:
– log_bin=mysql-bin

• Y el filtrado se realiza en el slave:
– replicate-do-db (no!)
– replicate-ignore-db (no!)
– replicate-wild-do-table (si)

• Límites:
– Un Slave solo puede tener un Master.



Replicación - Introducción

• Valores recomendados para la replicación:
– sync_binlog (escritura forzada a disco)
– slave-net-timeout (tiempo que debe transcurrir para que el slave de por caida la conexión)
– master-connect-retry (tiempo entre intentos de conexión)

• Para comprobar el estado del master:
– show master status;

• Para comprobar el estado del slave:
– show slave status;

• Arrancar procesos slave:
– start slave;

• Parar procesos slave:
– stop slave;




• Para montar la replicación es necesario conocer la posición y fichero en el cual se encuentra el
log binario
• Si no hay actividad es sencillo, siempre estará en la misma posición
• Si hay actividad no es tan facil, es necesario sacar una copia consistente en un punto concreto

mysqldump --master-data=1

• Con esta opción incluimos en el dump el fichero y posición en el cual se comenzó el backup.
• Se recomienda un bloqueo de tablas.

mysql> show master status;
+-------------------+-----------+--------------+------------------+
| File | Position | Binlog_Do_DB | Binlog_Ignore_DB |
+-------------------+-----------+--------------+------------------+
| mysqld-bin.004446 | 787553149 | | |
+-------------------+-----------+--------------+------------------+
1 row in set (0.00 sec)




• Creamos un usuario para que el slave se pueda conectar al master:

mysql> CREATE USER 'repl'@‘10.10.0.2' IDENTIFIED BY 'slavepass';
mysql> GRANT REPLICATION SLAVE ON *.* TO 'repl'@‘10.10.0.2';

• Una vez hecho, lo conectamos al master:

mysql> CHANGE MASTER TO

-> MASTER_HOST=’10.10.0.1',

-> MASTER_USER='repl',

-> MASTER_PASSWORD=‘slavepass',

-> MASTER_PORT=3306,

-> MASTER_LOG_FILE='master2-bin.001',

-> MASTER_LOG_POS=4;



*************************** 1. row ***************************
Slave_IO_State: Waiting for master to send event
Master_Host: xxxxx-y.servidoresdns.net
Master_User: masteruser
Master_Port: 3306
Connect_Retry: 60
Master_Log_File: mysqld-bin.004446
Read_Master_Log_Pos: 901561386
Relay_Log_File: mysqld-relay-bin.000605
Relay_Log_Pos: 901561524
Relay_Master_Log_File: mysqld-bin.004446
Slave_IO_Running: Yes
Slave_SQL_Running: Yes
Replicate_Do_DB:
Replicate_Ignore_DB:
Replicate_Do_Table:
Replicate_Ignore_Table:
Replicate_Wild_Do_Table: xxxx.%
Replicate_Wild_Ignore_Table:
Last_Errno: 0
Last_Error:
Skip_Counter: 0
Exec_Master_Log_Pos: 901561386
Relay_Log_Space: 901561524
Until_Condition: None
Until_Log_File:

Dpto. Soporte SSAA - 10 - September 25, 2011


Replicación – Master Slave

• La separación de escrituras/lecturas se debería hacer a nivel de aplicación
– O con un balanceador de capa 7
– O con software de terceros (MySQL Proxy, Tungsten, etc.) Hace falta KnowHow.

• Se pueden balancear las lecturas entre los diferentes esclavos usando un balanceador hardware
o software (keepalived, HAProxy…). Importante chequeos de salud

• Importante recordar, la replicación es asíncrona. Puede ser que el esclavo no esté a la par con el
maestro. Este punto es necesario conocerlo y darlo a conocer

• Los esclavos, en función del tipo de querys, necesitarán un tunning diferente al que se
establezca en el maestro



Replicación – Master Master
Maestro-Maestro

● Lo que se escribe en uno se replica en el otro.
● Se puede escribir en los dos.




• Balancear las escrituras entre los dos masters no supone repartir carga, ¡los dos tienen que
escribir los datos!
• Al no existir transacciones distribuidas, un lock en master1 no es un lock en master2, por lo que
tendrás datos inconsistentes
• Resumiendo

NO HAY ESCALABILIDAD A NIVEL DE ESCRITURAS,
NO SE PUEDEN BALANCEAR

• Se debe escribir en un nodo o en otro, pero no en los dos al mismo tiempo.
• Por ejemplo, Keepalived + VRRP, DRBD + Heartbeat, etc. ¡Balanceo de IP!
• Balancear una IP, que será contra la que ataque la aplicación, y que esta salte de un nodo a otro
si se produce alguna caida.
• El balanceo de Ips habrá que consultarlo con redes ¿Problemas en cloud con las MAC Address?
¿Asignación de Ips por puerto de Switch?
• Cuidado con los Split Brains




• Como hemos dicho, un esclavo solo tiene un maestro. Por lo tanto, todos los esclavos apuntarán
a un único maestro
• Si el maestro se cae ¿Qué pasa con los esclavos?
• No hay failover automático, estos seguirán apuntando al servidor caido
• Se podría solucionar apuntando los esclavos a una ip virtual, pero… ¿tienen los dos maestros los
ficheros binarios en la misma posición y con el mismo nombre? A-S-I-N-C-R-O-N-O
• Para la arquitectura anterior, los dos maestros necesitarían compartir el mismo /var/lib/mysql y
tener una IP balanceada
– Heartbeat
– DRBD

• Existen soluciones para escalar las escrituras, pero necesitaría mucho testing, formación,
comprobar que la solución se adapta al cliente y explicarle su funcionamiento, por ejemplo Spider
SQL. Por lo tanto, no recomendable.

• Cada cliente tiene una forma de trabajar, una aplicación, unas necesidades diferentes. Hay que
estudiar cada caso por separado y ver que como se adapta



Replicación - Circular
Circular

● Lo que se escribe en uno se replica en el siguiente, este en el siguiente, este en... A → B →
C→D→A
● Es la menos recomendable. En realidad está casi prohibida ;)



Replicación - Circular
Circular

● Es una forma de disponer de más de dos servidores en arquitectura maestro-maestro.
● Contra más sean los hosts implicados, mayor el caos de su administración.
● A→B→C→D→E→A
● Si el host C se cae (por ejemplo) la replicación se rompe. Lo escrito en B no se replica, lo
escrito en D se replica en todos menos en C, etc.
● Si se cae por ejemplo B y D, el caos es infinito. La solución es salir corriendo.
● A no ser que no exista otra solución, no se recomienda.



Replicación – Limitaciones

• Existen una serie de limitaciones en las replicaciones a tener en cuenta
– La aplicación de los cambios en el esclavo son lineales, single thread
– No existen transacciones distribuidas
– Los logs binarios se corrompen
– La replicación es asíncrona, maestro y esclavo no van a la par
– No existe comprobación activa de integridad
– No hay failover automático
– No hay balanceo automático
– No hay repair automático
– Un esclavo solo puede tener un único maestro



Replicación – Soluciones de terceros MMM
MMM



MMM

● Escrito en Perl…
● Características:
– Monitorización de la replicación
– Monitorización de los hosts
– Gestión del failover
– Balanceo de IPs entre nodos
– Gestión de grupos de escritura/lectura
● La alta disponibilidad se hace mediante el balanceo de Ips virtuales que saltarán de un
servidor a otro en caso de ser necesario.
– Exclusivo: Una única IP para muchos hosts. Si el host que la tiene se cae se balancea a
otro. Generalmente se usa en los nodos de escritura.
– Balanceado: Una IP por cada host. Si uno de los hosts se cae la IP se balancea a
cualquier otro, pasando a tener dos IPs virtuales. Se usa para nodos en lectura.




• Se necesita un nodo más, que será el nodo de control
• La separación de escrituras y lecturas se tiene que seguir haciendo a nivel de aplicación
• Nos da balanceo de Ips en nodos maestro y esclavo
• Es una alternativa a lo visto anteriormente, DRBD + Heartbeat
• Software libre, acceso a código fuente y sin coste
• Soporte empresarial por parte de Percona http://www.percona.com



Replicación – Galera Multi Master Síncrona

• Existe una solución llamada MySQL Galera, que nos proporciona replicación Síncrona y Multi
Master
http://www.codership.com/products/mysql_galera

• Dispone de transacciones y bloqueo de tablas distribuido
• Es síncrono, hasta que todos los nodos no hagan commit no se devuelve el resultado de la
transacción
• Todos los nodos están a la par, no se producen latencias en la replicación
• ¡Es una modificación de InnoDB! Por lo tanto, solo vale para tablas InnoDB
• Es software libre, por lo que tenemos acceso al código fuente y no tiene coste de licencias
• Hay soporte comercial por parte de Codership.



Replicación - Tungsten

• http://www.continuent.com/
• Es un sistema de replicación escrito en Java que corre una capa por encima de MySQL y
PostgreSQL.
• Soporta replicación de MySQL a PostgreSQL y Oracle.
• Y más cosas:
– Filtro de transacciones
– Time delay replication
– Chequeos de consistencia
– Replicación multi-master
– Replicación en paralelo
– Read/Write Splitting
– Balanceo de lecturas
– IPs balanceadas

http://www.continuent.com/solutions/featurematrix



Replicación - Sandbox
SandBox

● Para crear una laboratorio de pruebas podemos:
– Montar equipos físicos e instalarlos (de locos).
– Montar máquinas virtuales.
– Usar ¡sandbox!


SandBox

● SandBox nos permite:
– Montar sistemas de replicación
– Probar versiones nuevas de MySQL fácilmente
– Manejar múltiples instancias de MySQL desde un único punto.
– Te olvidas de rmps, sources, debs... ¡tar.gz binario!
– Testear
– Testear
– Testear...


SandBox

● No es un producto oficial de MySQL.
● Está escrito el perl…

http://mysqlsandbox.net/
● Tendremos que descargar un paquete tar.gz de MySQL y
Sandbox.


Instalación

● ¡Como root!

[root@localhost]# perl Makeﬁle.PL
[root@localhost]# make
[root@localhost]# make install

● Listo.


Uso de SandBox

● Installing /usr/bin/make_multiple_sandbox
● Installing /usr/bin/make_sandbox_from_source
● Installing /usr/bin/test_sandbox
● Installing /usr/bin/sbtool
● Installing /usr/bin/make_sandbox
● Installing /usr/bin/sb
● Installing /usr/bin/make_replication_sandbox
● Installing /usr/bin/msandbox
● Installing /usr/bin/make_sandbox_from_installed
● Installing /usr/bin/low_level_make_sandbox
● Installing /usr/bin/make_multiple_custom_sandbox



• Crear una replicación Master-Slave con dos nodos

root@localhost ~]# make_replication_sandbox --how_many_slaves=2 /root/
mysql-5.5.10-linux2.6-x86_64.tar.gz
installing and starting master
installing slave 1
installing slave 2
starting slave 1
.. sandbox server started
starting slave 2
.. sandbox server started
initializing slave 1
initializing slave 2
replication directory installed in $HOME/sandboxes/rsandbox_5_5_10



Uso de SandBox

● Parar sandbox:
– stop
● Arrancar sandbox:
– start
● Utilizar sandbox:
– use
● Reiniciar sandbox:
– restart
● Limpiar el sandbox:
– clean


Crear entorno maestro-esclavo

● Acceder al maestro
– m1
● Acceder al esclavo 1
– s1
● Acceder al esclavo 2
– s2
● Chequear esclavos
– check_slaves


Replicación - Resumen

• Cosas a recordar:
– No se puede balancear la carga en escrituras
– Para escalar escrituras, hay que escalar verticalmente
– La separación de lecturas/escrituras se debe hacer a nivel de aplicación
– Las lecturas se pueden balancear con un simple balanceador hardware o software con
chequeos de salud
– La replicación es asíncrona
– Las replicaciones se rompen
– No existen proceso automáticos de reparación, son manuales (técnico)
– Si un Master se cae, el Slave no se autopromociona a Master. Proceso manual.
– Un slave solo puede tener un único máster, lo que limita el tipo de arquitectura a diseñar
– La alta disponibilidad en Masters necesita balanceo de IP y en algunos casos DRBD
– Es recomendable el chequeo activo y constante de la integridad de datos en Master Master
– Existen soluciones de terceros que funcionan bien, pero se necesita KnowHow
– Cada solución debe ser estudiada al detalle, no hay una regla universal
– Si a un cliente le sirve una solución, eso no la convierte en la plantilla para todos los demás
– Cuidado con los Split Brain. Si se cae el Switch, estamos vendidos
– Y muchas más cosas… 



MySQL Cluster

MySQL Cluster



MySQL Cluster - Introducción

• MySQL Cluster es la versión de MySQL pensada para Alta Disponibilidad, Escalabilidad y Alto
Rendimiento
• La configuración y puesta en marcha difiere completamente de la versión estandar de la base de
datos
• Requiere gran cantidad de memoria RAM
– Índices en RAM siempre
– Datos en RAM o en disco duro
• El engine es ndbcluster, no se puede usar InnoDB o MyISAM en cluster
• No es una base de datos de propósito general
– Subqueries lentas
– Joins lentas
– No soporta integridad referencial y claves externas
– No hay rollbacks parciales ni savepoints, solo rollbacks completos
– No se garantiza el commit



MySQL Cluster – Tipos de nodos

• Para tener alta disponibilidad debes tener al menos 4 nodos
• Pero a modo de pruebas puedes montarlo en 1, 2 o 3. Pero solo para pruebas, o pierdes HA!
• mysqld
– Al cluster se puede acceder usando la API o mediante un servicio mysqld
– Al menos debemos tener dos nodos mysqld o tendremos un SPOF
• ndbd
– Ndbd son los nodos de almacenamiento. Estos deben tener la capacidad de procesamiento
y la memoria RAM suficiente para trabajar con los datos.
– Al menos debemos tener dos nodos ndbd
– Si queremos usar múltiples cores, el demonio será ndbmtd
• ndbd_mgm
– Es el nodo de Management. Tiene la configuración del cluster
– No es necesario más de uno, pero consume tan poco que se pueden tener dos
– Nosotros lo usamos para lanzar backups, reiniciar nodos, activar el log…
– Los nodos ndbd lo usan al entrar en el cluster para recoger la configuración




• La web de MySQL recomienda 5 servidores:
– 2 ndbd
– 2 mysqld
– 1 ndb_mgmd
• Podemos mejorar esta arquitectura y hacerla mas barata montando un ndb_mgmd en cada
mysqld:
– 2 ndbd
– 2 mysqld + ndb_mgmd
• De esta forma mejoramos la recomendación de MySQL, añadiendo HA a ndb_mgmd y
ahorrándonos un servidor
• Todo lo que se monte reduciendo esa arquitecturá funcionará igualmente, pero has perdido el HA
• ¿Para que quieres un MySQL Cluster, si luego el diseño de la arquitectura es erroneo?
• No se debe juntar mysqld y ndbd en un mismo host, son los nodos que más consumen y
degradará el rendimiento




• Además de decidir cuantos nodos tendrá nuestro cluster, hay que decidir cuantas réplicas se
configurarán
• Una réplica es una copia completa de la BBDD
• Los nodos de almacenamiento se dividen en node groups automáticamente
• La fórmula es muy complicada:
N/R=G
• Donde N es número de nodos, R número de réplicas y G número resultante de grupos
• 2 nodos / 2 réplicas = 1 grupo de nodos
• 4 nodos / 2 réplicas = 2 grupos de nodos
• 5 nodos / 2 réplicas = ERROR

• La base de datos será accesible y funcional siempre y cuando no se pierda ningún node group
• Un grupo de nodos está vivo siempre y cuando quede un nodo vivo dentro del grupo
• El número de particiones será igual al número de data nodes




Node Group 1

Node Group 2



MySQL Cluster - Configuración

• El fichero de configuración lo carga el nodo de management. Tiene la siguiente estructura:

[NDBD DEFAULT]
[NDB_MGMD]
[MYSQLD DEFAULT]
[API DEFAULT]
[NDB_MGMD]
[NDBD]
[MYSQLD]
[API]

• Cada nodo tiene su propio fichero de configuración en /etc/my.cnf con los parámetros de
arranque definidos




[NDBD DEFAULT]
NoOfReplicas=2
LockPagesInMainMemory=1
DataDir=/var/lib/mysql-cluster
DataMemory=5120M
IndexMemory=512M
ODirect=1
NoOfFragmentLogFiles=300
MaxNoOfConcurrentOperations=100000
TimeBetweenGlobalCheckpoints=1000
TimeBetweenEpochs=200
DiskCheckpointSpeed=10M
DiskCheckpointSpeedInRestart=100M
RedoBuffer=32M
MaxNoOfTables=1024
MaxNoOfAttributes=10000
MemReportFrequency=3600
BackupReportFrequency=10
LogLevelStartup=15
LogLevelShutdown=15
LogLevelCheckpoint=8
LogLevelNodeRestart=15
MaxNoOfExecutionThreads=8




[NDB_MGMD]
NodeId=1
HostName=192.168.0.33
DataDir=/var/lib/mysql-cluster

[NDBD]
NodeID=2
HostName=192.168.0.32

[NDBD]
NodeId=3
HostName=192.168.0.31

[MYSQLD]
NodeId=4
HostName=192.168.0.30

[API]
NodeId=5




• Par salvaguardar los datos se hacen dos checkpoints
• LocalCheckpoint:
– Es un checkpoint a nivel de nodo
– Se realiza en todos los nodos de forma más o menos concurrente
– Cuando se hace un LCP, el nodo local guarda los datos al disco duro
– El valor no es segundos , es una fórmula que da como resultado megas de datos
– Si por ejemplo, el valor es 20:
• 4 × 220
– 4194304 = 4 MB
– Cada 4MB los nodos harán checkpoint

• GlobalCheckpoint:
– Es un checkpoint… global
– Las transacciones de los nodos se sincroniza y los redo log se escriben a disco duro
– El valor es en milisegundos




• NoOfFragmentLogFiles
• Indica el número de redo log files
• Los redo logs se escriben en anillo, la cabeza nunca debe encontrarse con la cola
• Los redo log de una transacción no se borran hasta que no pasan dos LocalCheckpoint desde
que se escribió el dato
• El parámetro por defecto es 16
• 16 grupos de 4 ficheros de 16 megas = 1024 megas
• Este valor no se puede cambiar en caliente, necesita reiniciarse el cluster con --initial




• El Nodo MySQL debe conocer la IP del Management
• Además, se pueden configurar todas las opciones de cacheo y buffer como en cualquier otro
mysqld

[client]
port=3306
socket=/var/lib/mysql/mysql.sock

[mysqld]

ndbcluster
# IP address of the cluster management node
ndb-connectstring=192.168.0.33
default-storage-engine=NDBCLUSTER
max_connections=1000
query_cache_size=16M

[mysql_cluster]
# IP address of the cluster management node
ndb-connectstring=192.168.0.33
• El binario es mysqld




• Para saber en que grupos se debe poner la configuración:

[root@xxxxxx ~]# mysqld --verbose --help | head -n 30
110307 9:07:42 [ERROR] Fatal error: Please read "Security" section of the manual to ﬁnd out how to run mysqld as root!

mysqld Ver 5.1.51-ndb-7.1.10-cluster-gpl for unknown-linux-gnu on x86_64 (MySQL Cluster Server (GPL))
Copyright (C) 2000-2008 MySQL AB, by Monty and others.
Copyright (C) 2008 Sun Microsystems, Inc.
This software comes with ABSOLUTELY NO WARRANTY. This is free software,
and you are welcome to modify and redistribute it under the GPL license

Starts the MySQL database server.

Usage: mysqld [OPTIONS]

Default options are read from the following ﬁles in the given order:
/etc/mysql/my.cnf /etc/my.cnf ~/.my.cnf
The following groups are read: mysql_cluster mysqld server mysqld-5.1




• Para los nodos ndbd se sigue el mismo procedimiento:
– Conocer la sección del my.cnf
– Indicar la IP del management
– Insertar más opciones si se desea (--help)
• Por ejemplo:

[root@llwg052-y ~]# cat /etc/my.cnf
[ndbd]
ndb-mgmd-host = 192.168.0.33

• El nodo management le dará un NodeId dependiendo de la IP de donde se conecte.
• Hay dos binarios:
– nbdb para monocore
– ndbmtd para multicore
• La primera vez que pongamos en marcha los nodos se deberán arrancar con --initial
• Hasta que los nodos no estén en macha, mysqld no se podrá conectar




• Orden de arranque
– ndb_mgmd
– ndbmtd 1
– ndbmtd 2
– ndbmtd X
– mysqld
• Cuando todo esté en marcha, podremos hacer uso de la consola de management
[root@xxxxx ~]# ndb_mgm
-- NDB Cluster -- Management Client --
ndb_mgm> show
Connected to Management Server at: localhost:1186
Cluster Conﬁguration
---------------------
[ndbd(NDB)]
2 node(s)
id=2
@192.168.0.32 (mysql-5.1.51 ndb-7.1.10, Nodegroup: 0, Master)
id=3
@192.168.0.31 (mysql-5.1.51 ndb-7.1.10, Nodegroup: 0)

[ndb_mgmd(MGM)]
1 node(s)
id=1
@192.168.0.33 (mysql-5.1.51 ndb-7.1.10)

[mysqld(API)]
2 node(s)
id=4
@192.168.0.30 (mysql-5.1.51 ndb-7.1.10)
id=5 (not connected, accepting connect from any host)



MySQL Cluster - Backup

• El backup se puede lanzar desde la consola de management

START BACKUP [<backup id>] [NOWAIT | WAIT STARTED | WAIT COMPLETED]
ABORT BACKUP <backup id>

• Cada nodo de almacenamiento hará backup de sus datos en disco local

• Metadatos
– BACKUP-backup_id.node_id.ctl
• Datos de las tablas
– BACKUP-backup_id-0.node_id.data
• Log de transacciones
– BACKUP-backup_id.node_id.log

• El backup siempre es completo




• Se hace con la utilidad de consola ndb_restore
• A la hora de restaurar es necesario:
– Disponer todos los datos de backup de los nodos en una sola carpeta
– Que le nodo desde el que se lanza el backup tenga acceso al management
• Por defecto intentará restaurar todo, metadatos y datos
• Si ve que la tabla existe, no sobreescribirá, dará error
• Será necesario hacer uso de:
– include-databases
– exclude-databases
– include-tables
– exclude-tables
• Si no se indica connect-string se hará conectará a localhost




• Restauramos metadatos:

ndb_restore -n 3 -m -b 4 --include-tables=employees.salaries /tmp/BACKUP-02032011/
Nodeid = 3
Backup Id = 4
backup path = /tmp/BACKUP-02032011/
Including tables: employees.salaries
Opening file '/tmp/BACKUP-02032011/BACKUP-4.3.ctl'
Backup version in files: ndb-6.3.11 ndb version: mysql-5.1.51 ndb-7.1.10
Stop GCP of Backup: 59800
Connected to ndb!!
Successfully restored table èmployees/def/salaries`
Successfully restored table event REPL$employees/salaries
Successfully created index `PRIMARY` on `salaries`
Successfully created index èmp_no` on `salaries`

NDBT_ProgramExit: 0 - OK




• Restauramos datos:

ndb_restore -n 3 -r -b 4 --include-tables=employees.salaries /tmp/BACKUP-02032011/
Nodeid = 3
Backup Id = 02032011
backup path = /tmp/BACKUP-4/
Including tables: employees.salaries
Opening file '/tmp/BACKUP-4/BACKUP-4.3.ctl'
Backup version in files: ndb-6.3.11 ndb version: mysql-5.1.51 ndb-7.1.10
Stop GCP of Backup: 59800
Connected to ndb!!
Opening file '/tmp/BACKUP-4/BACKUP-4-0.3.Data'
_____________________________________________________
Processing data in table: employees/def/employees(7) fragment 1
_____________________________________________________
Processing data in table: mysql/def/ndb_schema(4) fragment 1
[…]
Opening file '/tmp/BACKUP-4/BACKUP-1032011.3.log'
Restored 0 tuples and 0 log entries

NDBT_ProgramExit: 0 - OK



Se acabó

¿Preguntas?



MySQL - High Availability - Load Balacing - Cluster

Más contenido relacionado

La actualidad más candente (19)

Destacado (20)

Similar a MySQL - High Availability - Load Balacing - Cluster (20)

Más de Miguel Angel Nieto (10)

Último (20)

MySQL - High Availability - Load Balacing - Cluster