MYSQL FABRIC GUÍA PARA ADMINISTRAR MYSQL ALTA DISPONIBILIDAD Y ESCALABILIDAD - INFORME DE MYSQL
←
→
Transcripción del contenido de la página
Si su navegador no muestra la página correctamente, lea el contenido de la página a continuación
MySQL Fabric
Guía para administrar MySQL Alta
disponibilidad y Escalabilidad
Informe de MySQL®
Septiembre de 2014
Copyright © 2014, Oracle y/o sus filiales. Todos los derechos reservados.
Tabla de contenidos
1 RESUMEN EJECUTIVO ......................................................................................................................................3
2 QUÉ PROPORCIONA MYSQL FABRIC ................................................................................................................4
2.1 ALTA DISPONIBILIDAD ................................................................................................................................................4
2.1.1 Diferentes puntos de alta disponibilidad ..........................................................................................................4
2.1.2 Duplicación MySQL ...........................................................................................................................................5
2.1.3 Qué agrega MySQL Fabric en términos de alta disponibilidad .........................................................................6
2.2 ESCALABILIDAD, PARTICIONAMIENTO ............................................................................................................................7
2.3 APROVISIONAMIENTO DEL SERVIDOR ............................................................................................................................7
3 DÓNDE SE SITÚA MYSQL FABRIC CON LAS OTRAS OFERTAS MYSQL DE ORACLE .............................................8
4 LIMITACIONES ACTUALES ................................................................................................................................9
5 DISEÑADO PARA LA EXTENSIBILIDAD ..............................................................................................................9
6 CÓMO PRACTICAR, TUTORIALES ...................................................................................................................10
6.1 AGREGAR ALTA DISPONIBILIDAD ................................................................................................................................10
6.2 AGREGAR ESCALABILIDAD CON PARTICIONAMIENTO .......................................................................................................19
7 PRÁCTICAS OPERATIVAS RECOMENDADAS ...................................................................................................26
7.1 ORACLE UNIVERSITY ...............................................................................................................................................26
7.2 CONSULTORÍA MYSQL ............................................................................................................................................26
7.2.1 MySQL Enterprise Edition y MySQL Cluster Carrier Grade Edition (CGE) ........................................................27
8 CONCLUSIÓN .................................................................................................................................................29
9 RECURSOS ADICIONALES ...............................................................................................................................29
Copyright © 2014, Oracle y/o sus filiales. Todos los derechos reservados. Página 2
1 Resumen ejecutivo
MySQL es famosa por ser una base de datos muy sencilla de utilizar y con el motor de almacenamiento InnoDB
que brinda gran desempeño, funcionalidad y confiabilidad.
MySQL/InnoDB ahora escala muy bien a medida que se agregan más núcleos al servidor y esto mejora con cada
lanzamiento pero hasta un punto que se alcanza el límite y el escalamiento no es suficiente. Puede ocurrir que
esté utilizando la máquina más grande que está disponible o que sea más económico utilizar servidores múltiples
y de bajo costo. La escalabilidad es una tarea sencilla si utiliza duplicación MySQL, obtenga un servidor MySQL
maestro para lidiar con todas las operaciones de escritura y luego establezca un balance a través de cuantos
servidores esclavos MySQL necesite. ¿Qué sucede cuando un maestro único falla? La alta disponibilidad (HA)
también hace frente a las fallas con la conexión a aplicaciones
móviles y servicios globales, el concepto de “ventana de
mantenimiento” donde el tiempo de inactividad del sistema puede ser
programado es una cosa del pasado para la mayoría de las
aplicaciones.
Tradicionalmente ha sido el trabajo de la aplicación o de DBA el
detectar fallas y promocionar uno de los esclavos para que sea el
nuevo maestro. El hecho de que el sistema completo se haga
altamente disponible puede volverse complejo y virar el desarrollo y
los recursos operativos lejos de las tareas de valores más altos que
generan ingresos.
Mientras que la duplicación MySQL proporciona el mecanismo para
escalar las operaciones de lectura, un único servidor debe manejar todas las operaciones de escritura y a
medida que las aplicaciones modernas se vuelven cada vez más interactivas, la proporción de las operaciones
de escritura seguirá en aumento. La ubicuidad de los medios sociales implica que la antigüedad de la publicación
y la lectura de un sitio web están finalizadas. Añádase a esto la promesa que ofrecen las plataformas en la nube,
una escalabilidad masiva y elástica de la infraestructura subyacente y se obtiene una enorme demanda de
escalabilidad a docenas, cientos o incluso miles de servidores.
La manera más común de escalabilidad es el particionamiento de los datos entre múltiples servidores MySQL,
esto puede realizarse verticalmente (cada servidor contiene un subconjunto discreto de tablas para un conjunto
específico de funciones) u horizontalmente donde cada servidor tiene un subconjunto de filas para una tabla
dada. A pesar de ser efectivo, el particionamiento requiere que los desarrolladores y DBA dediquen sus
esfuerzos en la construcción y el mantenimiento de lógica compleja en capas de aplicación y administración,
y una vez más detractar actividades de valor más alto.
La introducción de MySQL Fabric hace que todo sea más simple. MySQL Fabric está diseñada para administrar
grupos de servidores MySQL, ya sea para pocos de alta disponibilidad o miles para lidiar con la escalabilidad de
aplicaciones web.
Para la alta disponibilidad, MySQL Fabric administrará las relaciones de replicación, detectará la falla del
maestro y promocionará automáticamente uno de los esclavos para que sea el nuevo maestro. Esto es
completamente transparente para la aplicación.
Para la escalabilidad, MySQL Fabric automatiza el particionamiento con los requisitos de conectores de
enrutamiento para el servidor (o servidores si también utiliza MySQL Fabric para alta disponibilidad) basado en
una clave de particionamiento proporcionada por la aplicación. Si una partición incrementa de tamaño, MySQL
Fabric puede dividir la partición a medida que garantiza que los requisitos continúan enviándose a la ubicación
correcta.
MySQL Fabric proporciona una opción simple y efectiva para la alta disponibilidad como así también la opción de
escalabilidad y de incremento gradual. Realiza esto sin sacrificar la potencia de MySQL e InnoDB; lo que
requiere cambios importantes para la aplicación o necesita los equipos de desarrollo de operaciones para pasar
a tecnologías desconocidas o abandonar sus herramientas favoritas.
Este informe se enfoca en las capacidades de MySQL Fabric con mayor profundidad para luego pasar a ofrecer
un ejemplo práctico de su uso, inicialmente para proporcionar alta disponibilidad y luego añadir el
particionamiento.
Copyright © 2014, Oracle y/o sus filiales. Todos los derechos reservados. Página 3
2 Qué proporciona MySQL Fabric
MySQL Fabric está construida alrededor de un marco extensible para la administración de granjas de servidores
de MySQL. Actualmente se han implementado dos funciones: la alta disponibilidad y la escalabilidad con la
utilización de particionamiento de datos. Estas funciones se pueden utilizar separadas o en combinación.
Ambas funciones se implementan en dos capas:
El proceso de mysqlfabric que procesa los requisitos de administración, si recibe a través de mysqlfabric
1
command-line-interface (documentado en el manual de referencia ) u otro proceso a través de la interfaz
suministrada XML/RPC. Al utilizar la función de HA (alta disponibilidad), este proceso puede ser
responsable de monitorear el servidor maestro y de iniciar la conmutación por error para promocionar un
esclavo para que sea el nuevo maestro en caso de que falle. El estado de la granja de servidores se
lleva a cabo en el almacén de estado (una base de datos MySQL) y el proceso mysqlfabric es
responsable de proporcionar la información almacenada de enrutamiento a los conectores.
Los MySQL Connectors son utilizados por el código de aplicación para acceder a las bases de datos, lo
que convierte las instrucciones de un lenguaje de programación específico al protocolo de cables
MySQL, que se utiliza para comunicar con los procesos de servidores MySQL. Un conector compatible
con Fabric almacena un caché de la información de enrutamiento que se recolecta desde MySQL Fabric
y luego utiliza esa información para enviar transacciones o consultas al servidor MySQL correcto.
Actualmente los tres conectores MySQL compatibles con Fabric son para PHP, Python y Java (y a su
vez los marcos de doctrina e hibernación mapeo objeto relacional). Este enfoque significa que la latencia
y la potencia del cuello de botella para enviar todas las consultas a través de un proxy pueden ser
evitadas.
MySQL Fabric también proporciona el aprovisionamiento del servidor con la utilización de marcos en la nube
como OpenStack.
2.1 Alta disponibilidad
Alta disponibilidad (HA) se refiere a la capacidad que tiene un sistema para proporcionar un servicio continuo, un
servicio que está disponible mientras ese servicio se puede utilizar. El nivel de disponibilidad se expresa
generalmente en términos de “cantidad de nueves”, por ejemplo, un nivel de HA de 99,999% significa que el
servicio puede ser utilizado durante el 99,999% del tiempo, es decir, en promedio, el servicio no está disponible
por 5,25 minutos por año (eso incluye el tiempo de inactividad programado y no programado).
2.1.1 Diferentes puntos de alta disponibilidad
La Figura 1 representa las diferentes capas en el
sistema que deben estar disponibles para que se
proporcione el servicio.
En la parte inferior están los datos en los que se
basa el servicio. Obviamente si se pierden los datos,
el servicio no funcionará de manera correcta
y entonces es importante garantizar que haya al
menos una copia extra de esos datos. Estos datos
se pueden duplicar en la capa de almacenamiento
misma pero con MySQL son comúnmente
duplicados con la capa de arriba: el servidor MySQL
que utiliza la duplicación MySQL. El servidor MySQL
proporciona acceso a los datos, no tiene sentido que
los datos estén allí si no se puede acceder a ellos.
Es un error común pensar que tener redundancia en
estos dos niveles es suficiente para tener un sistema Figura 1 Alta disponibilidad superpuesta
de HA pero también es necesario tener en cuenta el
sistema de manera vertical.
1
http://dev.mysql.com/doc/mysql-utilities/en/fabric.html
Copyright © 2014, Oracle y/o sus filiales. Todos los derechos reservados. Página 4
Para tener un servicio de HA, debe haber redundancia en la capa de aplicación, en sí mismo esto es muy fácil,
simplemente debe equilibrar todas las solicitudes de servicio a través de un grupo de servidores de aplicaciones
que se ejecutan todos con la misma lógica de la aplicación. Si el servicio fuera algo tan simple como un
generador de números aleatorios entonces esto estaría bien, pero las aplicaciones más útiles necesitan acceder
a los datos, y a medida que se mueve más allá de un único servidor de base de datos (por ejemplo, porque tiene
que ser HA), entonces se requiere una forma para conectar el servidor de aplicaciones a la fuente de datos
correcta. En un sistema de HA, el enrutamiento no es una función estática, si un servidor de base de datos falla
(o que sea tomado por mantenimiento) la aplicación debe dirigirse en cambio a una base de datos alternativa.
Algunos sistemas de HA implementan esta función de enrutamiento al introducir un proceso de proxy entre la
aplicación y los servidores de base de datos, otros utilizan una dirección IP virtual que puede ser migrada al
servidor correcto. Cuando utiliza MySQL Fabric, esta función de enrutamiento se implementa dentro de la
biblioteca del conector MySQL compatible con Fabric que se utiliza para los procesos del servidor de
aplicaciones.
2.1.2 Duplicación MySQL
La duplicación MySQL se implementa al configurar una instancia como maestra, con una o más instancias
adicionales configuradas como esclavas. El maestro registra los cambios en la base de datos que luego son
enviados y aplicados a los esclavos de manera inmediata o luego de un tiempo de intervalo. La Figura 2 ilustra
este flujo de duplicación.
Figura 2 Duplicación MySQL
Además de HA, la duplicación MySQL generalmente se emplea para escalar la base de datos a través de un
clúster de servidores físicos, como se ilustra en la figura de abajo. Todas las operaciones de escritura
(y cualquier lectura que deba ser garantizada para recuperar los cambios más recientes) se dirigen al maestro,
mientras que otras declaraciones SELECT son dirigidas a los esclavos con la consulta de enrutamiento que se
implementa a través del conector apropiado MySQL (por ejemplo el conector/J JDBC o PHP drivers) o con la
lógica de la aplicación.
La duplicación MySQL se puede implementar en un rango de topologías para admitir escalabilidad diversa
y requisitos HA. Para obtener más información acerca de estas opciones y de cómo configurar la duplicación
1
MySQL, consulte el informe de duplicación .
La duplicación MySQL es un enfoque maduro y comprobado para cargas de trabajo de escalabilidad que
proporciona la base para HA.
1
http://www.mysql.com/why-mysql/white-papers/mysql-replication-introduction/
Copyright © 2014, Oracle y/o sus filiales. Todos los derechos reservados. Página 5
2.1.2.1 Duplicación semi simultánea MySQL
La duplicación semi simultánea puede utilizarse como alternativa a la duplicación asincrónica predeterminada de
MySQL que sirve para mejorar la integración de los datos.
Al utilizar la duplicación semi simultánea, se envía una confirmación al cliente únicamente cuando el esclavo
recibe la actualización. Por lo tanto se asegura que los datos existan en el maestro y en al menos un esclavo
(tenga en cuenta que el esclavo recibirá la actualización pero no se aplica necesariamente cuando se envía una
confirmación al maestro).
Es posible combinar los diferentes modos de duplicación como algunos esclavos MySQL que están configurados
con duplicación asincrónica mientras que otros utilizan duplicación semi simultánea. Esto significa que el
desarrollador / DBA puede determinar el nivel apropiado de consistencia de datos y el rendimiento en la base por
esclavo.
Los diferentes modos de duplicación que se describen arriba pueden mostrar la diferencia con la duplicación
simultánea completa por medio del cual los datos son enviados a dos o más instancias al mismo tiempo con la
utilización del protocolo “commit de dos fases”. La duplicación simultánea brinda consistencia garantizada a
través de sistemas múltiples y puede facilitar los tiempos de conmutación por error más rápidos pero puede
agregar gastos generales de rendimiento como resultado de mensajería adicional entre los nodos. La duplicación
1
simultánea es únicamente posible con MySQL Cluster que actualmente no es parte de MySQL Fabric.
2.1.3 Qué agrega MySQL Fabric en términos de alta disponibilidad
MySQL Fabric tiene el concepto de un grupo HA, que es un
grupo de dos o más servidores MySQL, y en un momento
determinado, uno de esos servidores es el primario (duplicación
maestra MySQL) y otros son secundarios (duplicación esclava
MySQL). El rol de un grupo HA es garantizar el acceso a los
datos albergados dentro de ese grupo para que estén siempre
disponibles.
Mientras que la duplicación MySQL permite que los datos
permanezcan seguros mediante la duplicación de los mismos,
para una solución HA se requieren de dos componentes extras
y MySQL Fabric los proporciona:
La detección de fallas y la promoción: el proceso
MySQL Fabric monitorea el primario dentro del grupo
HA y en el caso de que ese servidor falle selecciona
uno de los secundarios y lo promueve para que sea
primario (con todos los otros esclavos en el grupo HA
que recibirán actualizaciones del nuevo maestro).
Tenga en cuenta que los conectores pueden informar
a MySQL Fabric cuando observan un problema con el Figura 3 MySQL Fabric implementa HA
primario y el proceso MySQL Fabric utiliza esa
información como parte de ese proceso de toma de decisiones alrededor del estado de los servidores en
la granja de servidores.
Enrutamiento de solicitudes de base de datos: cuando MySQL Fabric promueve al nuevo primario,
actualiza el almacén de estado y esa nueva información de enrutamiento será recolectada por los
conectores y almacenada en los cachés. De esta manera, la aplicación no necesita saber que la
topología ha cambiado y que las operaciones de escritura se deben enviar a un destino diferente.
1
http://www.mysql.com/products/cluster/
Copyright © 2014, Oracle y/o sus filiales. Todos los derechos reservados. Página 6
2.2 Escalabilidad, particionamiento
Cuando se acerca al límite de capacidad o al
rendimiento de operaciones de escritura de un único
servidor MySQL (o grupo HA) se puede utilizar
a MySQL Fabric para escalar los servidores de base
de datos con la partición de los datos a través de
grupos múltiples de servidores MySQL. Tenga en
cuenta que un grupo puede contener un único servidor
MySQL o puede ser un grupo HA.
El administrador define cómo los datos deben ser
particionados dentro de estos servidores, esto se
realiza con la creación de las asignaciones de
partición. Una asignación de partición se aplica a un
conjunto de tablas y para cada tabla el administrador
especifica qué columna de esas tablas se debe utilizar
como clave de partición (la clave de partición será
utilizada por MySQL Fabric para calcular qué partición
de una fila específica de una de esas tablas debe ser
parte). Debido a que todas estas tablas utilizan la
misma clave de partición y asignación, el uso del
mismo valor de la columna en esas tablas puede dar Figura 4 MySQL Fabric implementa HA y el
lugar a que esas filas estén en la misma partición, lo particionamiento
que permite que con una transacción única se pueda
acceder a todas. Por ejemplo, si utiliza la columna de identificación del suscriptor desde varias tablas, todos los
datos para un suscriptor específico estarán en la misma partición. El administrador define cómo la clave de
partición debe utilizarse para calcular el número de partición:
HASH: la función hash se ejecuta en la clave de partición para generar el número de partición. Si los
valores en la columna utilizados como la clave de partición no tienden a tener muchos valores repetidos
entonces esto resulta en una partición de filas a través de las particiones.
RANGO: el administrador define una asignación explícita entre rangos de valores para la clave de
partición y las particiones. Esto le da máximo control al usuario de cómo se particionan los datos y qué
filas deben ser reubicadas.
Cuando la aplicación necesita acceder a la base de datos particionada, establece una propiedad para la
conexión que especifica la clave de partición, el conector compatible con Fabric aplicará el rango correcto o la
asignación hash y guiará la transacción a la partición correcta.
Si necesita más particiones/grupos, MySQL Fabric puede dividir una partición existente en dos y luego actualizar
el almacén de estado y los cachés de datos de enrutamiento contenidos por los conectores. De igual manera,
una partición puede moverse de un grupo HA a otro.
Tenga en cuenta que una única transacción o consulta solo puede acceder a una única partición y es por ello
que es importante seleccionar las claves de partición basadas en una comprensión de los datos y los patrones
de acceso de la aplicación. No siempre tiene sentido particionar todas las tablas ya que algunas son
relativamente pequeñas y tener los contenidos completos disponibles en cada grupo puede ser beneficioso
debido a la regla de que no hay consultas de partición cruzada. Estas tablas globales se escriben para un grupo
global y otras incorporaciones o cambios de los datos en esas tablas se duplican automáticamente en todos los
otros grupos. También se realizan cambios en los esquemas al grupo global y se duplican a todos los demás
para garantizar la consistencia.
Para obtener la mejor asignación, puede también ser necesario modificar el esquema si no hay una “opción
natural” para las claves de partición.
2.3 Aprovisionamiento del servidor
MySQL Fabric permite la escalabilidad elástica dentro y fuera de la granja de servidores administrados MySQL
con la utilización de marcos en la nube como OpenStack. MySQL Fabric asegura las máquinas de manera
transparente desde la nube antes de establecer MySQL y la duplicación e incluye los nuevos servidores.
Copyright © 2014, Oracle y/o sus filiales. Todos los derechos reservados. Página 73 Dónde se sitúa MySQL Fabric con las otras ofertas MySQL de Oracle
MySQL Fabric es una de las soluciones de MySQL HA y escalabilidad que ofrece Oracle. Estas soluciones están
enumeradas en Tabla 1 donde cada una se evalúa por una serie de criterios.
Tabla 1 Comparación de las tecnologías de MySQL HA y escalabilidad
1
Se pueden encontrar más detalles sobre otras soluciones en la guía MySQL para soluciones de alta disponibilidad .
MySQL Fabric tiene un número de funciones que lo hace adecuado para agregar cualquier escalabilidad, HA o
ambos a una aplicación basada en MySQL:
MySQL Fabric permite que la aplicación utilice el excelente y comprobado motor de almacenamiento
InnoDB.
La HA está construida sobre la duplicación MySQL que es una tecnología madura y utilizada alrededor
del mundo, lo que MySQL Fabric agrega es una capa de administración junto con la conmutación por
error automatizada que es transparente para la aplicación.
Escalamiento de operaciones de escritura junto con las operaciones de lectura.
Las arquitecturas Shared Nothing son ideales para hardware rentable y de mercancía mientras que
también aprovechan los servidores con varios núcleos.
Todos los elementos de la solución son respaldados por Oracle.
1
http://www.mysql.com/why-mysql/white-papers/mysql-guide-to-high-availability-solutions
Copyright © 2014, Oracle y/o sus filiales. Todos los derechos reservados. Página 84 Limitaciones actuales
La versión inicial de MySQL Fabric está diseñada para que sea simple, robusta y que permita escalar a miles de
servidores MySQL. Este enfoque significa que esta versión tiene un número de limitaciones, que se describen aquí:
La partición no es completamente transparente para la aplicación. Mientras que la aplicación no necesita
saber qué servidor almacena un conjunto de filas y no necesita saber adónde se trasladan los datos,
sí necesita proporcionar la clave de partición cuando se accede a la base de datos.
Las columnas de incremento automático no pueden ser utilizadas como clave de partición.
Todas las transacciones y consultas necesitan ser limitadas al ámbito de las filas que pertenecen a una
única partición, junto con las tablas globales (no particionadas). Por ejemplo, las uniones que involucran
múltiples particiones no son compatibles.
Debido a que los conectores ejecutan la función de enrutamiento, se evita la latencia extra involucrada
en las soluciones basadas en el proxy pero eso no significa que se necesiten los conectores compatibles
con Fabric, en el momento de escribir estos son parte de PHP, Python y Java.
El proceso MySQL Fabric en sí mismo no tolera fallas y debe ser reiniciado en el caso de que falle.
Tenga en cuenta que esto no representa un único punto de falla para la granja de servidores (HA y/o
particionamiento) ya que los conectores pueden continuar con las operaciones de enrutamiento con la
utilización de sus cachés locales mientras que el proceso MySQL Fabric no está disponible.
5 Diseñado para la extensibilidad
MySQL Fabric se diseñó para la extensibilidad en un número de niveles. Por ejemplo, en la primera versión, la
única opción para la implementación de HA se basa en la duplicación MySQL pero en futuras versiones
esperamos añadir más opciones (por ejemplo, MySQL Cluster). También esperamos ver aplicaciones
completamente nuevas en todo el manejo de granjas de servidores MySQL, ya sea de Oracle y la comunidad
más amplia de MySQL.
La Figura 5 ilustra cómo se pueden añadir nuevas aplicaciones y protocolos si se utiliza el marco conectable.
Figura 5 Arquitectura extensible MySQL Fabric
Copyright © 2014, Oracle y/o sus filiales. Todos los derechos reservados. Página 96 Cómo practicar: tutoriales
Esta sección se enfoca en cómo utilizar MySQL Fabric, inicialmente para proporcionar alta disponibilidad y luego
para la escalabilidad con la utilización del particionamiento. Se enfocará en la administración de las tareas pero
también se incluirán una serie de ejemplos de código Python para ilustrar lo que la aplicación tiene que hacer.
Para que sea más sencillo, este informe no abarca la configuración y el inicio de todos los servidores MySQL
(aparte de la que se utiliza para el almacén de estado de MySQL Fabric), un tutorial completo de extremo
a extremo (que incluye la configuración y la ejecución de todos los servidores MySQL) que se puede encontrar
1
en MySQL Fabric, que agrega alta disponibilidad y escalabilidad a MySQL . Además, si solo se requiere HA esto
2
está documentado en MySQL Fabric, agregar alta disponibilidad a MySQL y si solo se requiere escalabilidad
3
MySQL Fabric, agregar escalabilidad a MySQL .
Tenga en cuenta que como cualquier servidor MySQL en estos tutoriales puede ser un servidor primario
(duplicación maestro MySQL), los archivos de configuración deben permitir ID de transacciones globales así
como también registros binarios. A continuación hay un ejemplo de configuración de archivos:
[mysql@fab2 myfab]$ cat my2a.cnf
[mysqld]
datadir=/home/mysql/myfab/data2a
basedir=/home/mysql/mysql
socket=/home/mysql/myfab/mysqlfab2a.socket
binlog-format=ROW
log-slave-updates=true
gtid-mode=on
enforce-gtid-consistency=true
master-info-repository=TABLE
relay-log-info-repository=TABLE
sync-master-info=1
port=3306
report-host=fab2
report-port=3306
server-id=21
log-bin=fab2a-bin.log
6.1 Agregar alta disponibilidad
En esta sección se busca introducir MySQL Fabric para agregar alta disponibilidad a MySQL. Figura 6 ilustra la
configuración que se creará.
Va a haber un grupo único HA que tiene el nombre de group_id-1 que contendrá tres servidores MySQL, cada
uno se ejecuta en una máquina diferente (fab2, fab3 y fab4), y en un momento determinado, uno de esos
servidores MySQL será el primario (maestro) y los otros serán los secundarios. Si uno de los primarios falla, uno
de los secundarios será promovido automáticamente por el proceso MySQL Fabric para que sea el nuevo
primario.
El proceso MySQL Fabric en sí mismo se ejecutará en una cuarta máquina (fab1) junto con el almacén de
estado (otro servidor MySQL) y la aplicación de prueba que utiliza el conector de Python compatible con Fabric.
1
http://www.clusterdb.com/mysql-fabric/mysql-fabric-adding-high-availability-and-scaling-to-mysql
2
http://www.clusterdb.com/mysql-fabric/mysql-fabric-adding-high-availability-to-mysql
3
http://www.clusterdb.com/mysql-fabric/mysql-fabric-add-scaling-to-mysql
Copyright © 2014, Oracle y/o sus filiales. Todos los derechos reservados. Página 10El primer paso es instalar el conector Python así como también MySQL Fabric:
[root@fab1]# rpm -i mysql-connector-python-1.2.3-
1.el6.noarch.rpm
[root@fab1]# rpm -i mysql-utilities-1.5.2-1.el6.noarch.rpm
A continuación, el almacén de estado debe configurarse e iniciarse:
[mysql@fab1 myfab]$ mkdir data
[mysql@fab1 myfab]$ cat my.cnf
[mysqld]
datadir=/home/mysql/myfab/data
basedir=/home/mysql/mysql
socket=/home/mysql/myfab/mysqlfab.socket
binlog-format=ROW
log-slave-updates=true
gtid-mode=on
enforce-gtid-consistency=true
master-info-repository=TABLE
relay-log-info-repository=TABLE
sync-master-info=1
port=3306
report-host=fab1
report-port=3306
server-id=1
log-bin=fab-bin.log
[mysql@fab1 mysql]$ scripts/mysql_install_db \
--basedir=/home/mysql/mysql/ \ Figura 6 Grupo HA único
--datadir=/home/mysql/myfab/data/ \
--defaults-file=/home/mysql/myfab/my.cnf
mysql@fab1 ~]$ mysqld --defaults-file=/home/mysql/myfab/my.cnf &
La cuenta de usuario que se utilizará por MySQL Fabric se puede crear:
mysql@fab1 ~]$ mysql -h 127.0.0.1 -P3306 -u root -e \
'CREATE USER fabric@localhost; GRANT ALL \
ON fabric.* TO fabric@localhost;'
Tenga en cuenta que el esquema fabric no ha sido creado todavía, eso se realizará automáticamente por
MySQL Fabric.
Antes de iniciar MySQL Fabric, el archivo de configuración debe ser evaluado para garantizar que coincida con el
entorno real que será utilizado por los servidores MySQL y MySQL Fabric en sí mismo:
[root@fab1 mysql]# cat /etc/mysql/fabric.cfg
[DEFAULT]
prefix =
sysconfdir = /etc
logdir = /var/log
[logging]
url = file:///var/log/fabric.log
level = INFO
[storage]
auth_plugin = mysql_native_password
database = fabric
user = fabric
address = localhost:3306
connection_delay = 1
connection_timeout = 6
password =
connection_attempts = 6
Copyright © 2014, Oracle y/o sus filiales. Todos los derechos reservados. Página 11[failure_tracking]
notification_interval = 60
notification_clients = 50
detection_timeout = 1
detection_interval = 6
notifications = 300
detections = 3
failover_interval = 0
prune_time = 3600
[servers]
password =
user = fabric
[connector]
ttl = 1
[protocol.xmlrpc]
disable_authentication = no
ssl_cert =
realm = MySQL Fabric
ssl_key =
ssl_ca =
threads = 5
user = admin
address = localhost:32274
password = admin
[executor]
executors = 5
[sharding]
mysqldump_program = /home/mysql/mysql/bin/mysqldump
mysqlclient_program = /home/mysql/mysql/bin/mysql
1
Se pueden encontrar más detalles sobre estos parámetros de configuración en la documentación de MySQL Fabric .
El esquema dentro del almacén de estado puede ahora crearse y comprobarse (opcional):
[root@fab1 mysql]# mysqlfabric manage setup --param=storage.user=fabric
[INFO] 1399476439.536728 - MainThread - Initializing persister: user \
(fabric), server (localhost:3306), database (fabric).
[INFO] 1399476451.330008 - MainThread - Initial password for admin/xmlrpc set
Password set for admin/xmlrpc from configuration file.
[INFO] 1399476451.333563 - MainThread - Password set for admin/xmlrpc \
from configuration file.
[mysql@fab1 ~]$ mysql --protocol=tcp -u root
Welcome to the MySQL monitor. Commands end with ; or \g.
Your MySQL connection id is 5
Server version: 5.6.16-log MySQL Community Server (GPL)
Copyright (c) 2000, 2014, Oracle and/or its affiliates. All rights reserved.
Oracle is a registered trademark of Oracle Corporation and/or its
affiliates. Other names may be trademarks of their respective
owners.
1
http://dev.mysql.com/doc/mysql-utilities/en/fabric-configuration-file.html
Copyright © 2014, Oracle y/o sus filiales. Todos los derechos reservados. Página 12Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.
mysql>show databases;
+--------------------+
| Database |
+--------------------+
| information_schema |
| fabric |
| mysql |
| performance_schema |
| test |
+--------------------+
5 rows in set (0.00 sec)
mysql>use fabric;show tables;
Reading table information for completion of table and column names
You can turn off this feature to get a quicker startup with -A
Database changed
+-------------------+
| Tables_in_fabric |
+-------------------+
| checkpoints |
| error_log |
| group_replication |
| groups |
| permissions |
| role_permissions |
| roles |
| servers |
| shard_maps |
| shard_ranges |
| shard_tables |
| shards |
| user_roles |
| users |
+-------------------+
14 rows in set (0.00 sec)
El proceso MySQL Fabric puede iniciarse (tenga en cuenta que el proceso Fabric se puede ejecutar como
daemon al añadir la opción --daemonize:
[mysql@fab1 ~]$ mysqlfabric manage start
[INFO] 1399476805.324729 - MainThread - Fabric node starting.
[INFO] 1399476805.327456 - MainThread - Initializing persister: user (fabric), server
(localhost:3306), database (fabric).
[INFO] 1399476805.335908 - MainThread - Initial password for admin/xmlrpc set
Password set for admin/xmlrpc from configuration file.
[INFO] 1399476805.339028 - MainThread - Password set for admin/xmlrpc from configuration
file.
[INFO] 1399476805.339868 - MainThread - Loading Services.
[INFO] 1399476805.359542 - MainThread - Starting Executor.
[INFO] 1399476805.360668 - MainThread - Setting 5 executor(s).
[INFO] 1399476805.363478 - Executor-0 - Started.
[INFO] 1399476805.366553 - Executor-1 - Started.
[INFO] 1399476805.368680 - Executor-2 - Started.
[INFO] 1399476805.372392 - Executor-3 - Started.
[INFO] 1399476805.376179 - MainThread - Executor started.
[INFO] 1399476805.382025 - Executor-4 - Started.
[INFO] 1399476805.385570 - MainThread - Starting failure detector.
[INFO] 1399476805.389736 - XML-RPC-Server - XML-RPC protocol server ('127.0.0.1', 8080)
started.
[INFO] 1399476805.390695 - XML-RPC-Server - Setting 5 XML-RPC session(s).
Copyright © 2014, Oracle y/o sus filiales. Todos los derechos reservados. Página 13[INFO] 1399476805.393918 - XML-RPC-Session-0 - Started XML-RPC-Session.
[INFO] 1399476805.396812 - XML-RPC-Session-1 - Started XML-RPC-Session.
[INFO] 1399476805.399596 - XML-RPC-Session-2 - Started XML-RPC-Session.
[INFO] 1399476805.402650 - XML-RPC-Session-3 - Started XML-RPC-Session.
[INFO] 1399476805.405305 - XML-RPC-Session-4 - Started XML-RPC-Session.
Inicialmente habrá un solo grupo HA (esto es todo lo que se requiere para HA, después se añadirán grupos
adicionales para permitir la escalabilidad a través del particionamiento de los datos):
[mysql@fab1 myfab]$ mysqlfabric group create group_id-1
Procedure :
{ uuid = 7e0c90ec-f81f-4ff6-80d3-ae4a8e533979,
finished = True,
success = True,
return = True,
activities =
}
Antes de agregar los servidores MySQL al grupo, es necesario tener un usuario en cada servidor MySQL que
pueda acceder al servidor desde la máquina donde se ejecuta el proceso MySQL Fabric (en este ejemplo,
fab1/192.168.56.101). Para que sea más simple este informe utiliza el usuario root, sin contraseña y con el
permiso para acceder a todas las tablas desde cualquier host, esto es sólo para la experimentación y debe
utilizarse una seguridad más estricta en cualquier base de datos de producción.
[mysql@fab2 ~]$ mysql -h 127.0.0.1 -P3306 -u root -e 'GRANT ALL ON *.* TO fabric@"%"'
[mysql@fab3 ~]$ mysql -h 127.0.0.1 -P3306 -u root -e 'GRANT ALL ON *.* TO fabric@"%"'
[mysql@fab4 ~]$ mysql -h 127.0.0.1 -P3306 -u root -e 'GRANT ALL ON *.* TO fabric@"%"'
[mysql@fab2 ~]$ mysql -h 127.0.0.1 -P3306 -u root -e 'GRANT ALL ON *.* TO root@"%"'
[mysql@fab3 ~]$ mysql -h 127.0.0.1 -P3306 -u root -e 'GRANT ALL ON *.* TO root@"%"'
[mysql@fab4 ~]$ mysql -h 127.0.0.1 -P3306 -u root -e 'GRANT ALL ON *.* TO root@"%"'
MySQL Fabric ahora está disponible para acceder y manipular los servidores MySQL, por lo tanto ahora se
pueden añadir al grupo HA.
[mysql@fab1 myfab]$ mysqlfabric group add group_id-1 192.168.56.102:3306
Procedure :
{ uuid = 073f421a-9559-4413-98fd-b839131ea026,
finished = True,
success = True,
return = True,
activities =
}
[mysql@fab1 myfab]$ mysqlfabric group add group_id-1 192.168.56.103:3306
Procedure :
{ uuid = b0f5b04a-27e6-46ce-adff-bf1c046829f7,
finished = True,
success = True,
return = True,
activities =
}
[mysql@fab1 myfab]$ mysqlfabric group add group_id-1 192.168.56.104:3306
Procedure :
{ uuid = 520d1a7d-1824-4678-bbe4-002d0bae5aaa,
finished = True,
success = True,
return = True,
activities =
}
En este punto, todos los servidores MySQL actúan como secundarios (es decir, ninguno de ellos actúa como
maestro de duplicación MySQL). El próximo paso es promover uno de los servidores para que sea primario, en
este caso el uuid del servidor que queremos promover es proporcionado pero no requerido, en ese caso
MySQL Fabric seleccionará uno.
Copyright © 2014, Oracle y/o sus filiales. Todos los derechos reservados. Página 14[mysql@fab1 myfab]$ mysqlfabric group promote group_id-1 \
--slave_id 00f9831f-d602-11e3-b65e-0800271119cb
Procedure :
{ uuid = c875371b-890c-49ff-b0a5-6bbc38be7097,
finished = True,
success = True,
return = True,
activities =
}
[mysql@fab1 myfab]$ mysqlfabric group lookup_servers group_id-1
Command :
{ success = True
return = [
{'status': 'PRIMARY', 'server_uuid': '00f9831f-d602-11e3-b65e-0800271119cb', \
'mode': 'READ_WRITE', 'weight': 1.0, 'address': '192.168.56.104:3306'}, \
{'status': 'SECONDARY', 'server_uuid': 'f6fe224e-d601-11e3-b65d-0800275185c2', \
'mode': 'READ_ONLY', 'weight': 1.0, 'address': '192.168.56.102:3306'}, \
{'status': 'SECONDARY', 'server_uuid': 'fbb5c440-d601-11e3-b65d-0800278bafa8', \
'mode': 'READ_ONLY', 'weight': 1.0, 'address': '192.168.56.103:3306'}]
activities =
}
Tenga en cuenta que fab4 ahora se muestra como primario, cualquiera de los servidores secundarios también
pueden consultarse para confirmar que son efectivamente esclavos de duplicación MySQL del primario.
[mysql@fab1 ~]$ mysql -h 192.168.56.103 -P3306 -u root -e "show slave status\G"
*************************** 1. row ***************************
Slave_IO_State: Waiting for master to send event
Master_Host: 192.168.56.104
Master_User: fabric
Master_Port: 3306
Connect_Retry: 60
Master_Log_File: fab4-bin.000003
Read_Master_Log_Pos: 487
Relay_Log_File: fab3-relay-bin.000002
Relay_Log_Pos: 695
Relay_Master_Log_File: fab4-bin.000003
Slave_IO_Running: Yes
Slave_SQL_Running: Yes
Replicate_Do_DB:
Replicate_Ignore_DB:
Replicate_Do_Table:
Replicate_Ignore_Table:
Replicate_Wild_Do_Table:
Replicate_Wild_Ignore_Table:
Last_Errno: 0
Last_Error:
Skip_Counter: 0
Exec_Master_Log_Pos: 487
Relay_Log_Space: 898
Until_Condition: None
Until_Log_File:
Until_Log_Pos: 0
Master_SSL_Allowed: No
Master_SSL_CA_File:
Master_SSL_CA_Path:
Master_SSL_Cert:
Master_SSL_Cipher:
Master_SSL_Key:
Seconds_Behind_Master: 0
Master_SSL_Verify_Server_Cert: No
Last_IO_Errno: 0
Last_IO_Error:
Last_SQL_Errno: 0
Copyright © 2014, Oracle y/o sus filiales. Todos los derechos reservados. Página 15Last_SQL_Error:
Replicate_Ignore_Server_Ids:
Master_Server_Id: 40
Master_UUID: 00f9831f-d602-11e3-b65e-0800271119cb
Master_Info_File: mysql.slave_master_info
SQL_Delay: 0
SQL_Remaining_Delay: NULL
Slave_SQL_Running_State: Slave has read all relay log; waiting for the slave I/O \
thread to update it
Master_Retry_Count: 86400
Master_Bind:
Last_IO_Error_Timestamp:
Last_SQL_Error_Timestamp:
Master_SSL_Crl:
Master_SSL_Crlpath:
Retrieved_Gtid_Set: 00f9831f-d602-11e3-b65e-0800271119cb:1-2
Executed_Gtid_Set: 00f9831f-d602-11e3-b65e-0800271119cb:1-2,\
fbb5c440-d601-11e3-b65d-0800278bafa8:1-2
Auto_Position: 1
En esta etapa, la relación de duplicación MySQL está configurada y está ejecutándose pero todavía no hay alta
disponibilidad ya que MySQL Fabric no monitorea el estado de los servidores, la configuración final fija que:
[mysql@fab1 ~]$ mysqlfabric group activate group_id-1
Procedure :
{ uuid = 40a5e023-06ba-4e1e-93de-4d4195f87851,
finished = True,
success = True,
return = True,
activities =
}
Ahora está todo configurado para detectar si el primario (maestro) falla y en el caso de que lo haga, promover
uno de los secundarios para que sea el nuevo primario. Si utiliza uno de los conectores compatibles MySQL
Fabric (inicialmente PHP, Python y Java) la conmutación por error puede ser transparente para la aplicación.
El código que figura a continuación muestra cómo una aplicación puede acceder a este nuevo grupo HA, en este
caso, con la utilización de un conector Python. Primero se crea una tabla de aplicación:
[mysql@fab1 myfab]$ cat setup_table_ha.py
import mysql.connector
from mysql.connector import fabric
conn = mysql.connector.connect(
fabric={"host" : "localhost", "port" : 32274, "username": "admin",
"password" : "admin"},
user="root", database="test", password="",
autocommit=True
)
conn.set_property(mode=fabric.MODE_READWRITE, group="group_id-1")
cur = conn.cursor()
cur.execute(
"CREATE TABLE IF NOT EXISTS subscribers ("
" sub_no INT, "
" first_name CHAR(40), "
" last_name CHAR(40)"
")"
)
Tenga en cuenta el siguiente ejemplo de código:
El conector se proporciona con la dirección para el proceso MySQL Fabric localhost:32274 antes
que cualquier servidor MySQL
Copyright © 2014, Oracle y/o sus filiales. Todos los derechos reservados. Página 16 La propiedad mode para la conexión se establece en fabric.MODE_READWRITE lo cual el conector
interpretará que la transacción será enviada al primario (es allí donde todas las transacciones de
escritura se deben ejecutar para que sean duplicadas a los secundarios)
La propiedad group se ajusta a group_id-1 que es el nombre que se le dio al único grupo HA
Este código puede ser ejecutado y luego se puede comprobar en uno de los secundarios si la creación de la
tabla ha sido duplicada desde el primario.
[mysql@fab1 myfab]$ python setup_table_ha.py
[mysql@fab1 myfab]$ mysql -h 192.168.56.103 -P3306 -u root -e "use test;show tables;"
+----------------+
| Tables_in_test |
+----------------+
| subscribers |
+----------------+
El próximo paso es agregar más filas a la tabla:
[mysql@fab1 myfab]$ cat add_subs_ha.py
import mysql.connector
from mysql.connector import fabric
def add_subscriber(conn, sub_no, first_name, last_name):
conn.set_property(group="group_id-1", mode=fabric.MODE_READWRITE)
cur = conn.cursor()
cur.execute(
"INSERT INTO subscribers VALUES (%s, %s, %s)",
(sub_no, first_name, last_name)
)
conn = mysql.connector.connect(
fabric={"host" : "localhost", "port" : 32274, "username": "admin",
"password" : "admin"},
user="root", database="test", password="",
autocommit=True
)
conn.set_property(group="group_id-1", mode=fabric.MODE_READWRITE)
add_subscriber(conn, 72, "Billy", "Fish")
add_subscriber(conn, 500, "Billy", "Joel")
add_subscriber(conn, 1500, "Arthur", "Askey")
add_subscriber(conn, 5000, "Billy", "Fish")
add_subscriber(conn, 15000, "Jimmy", "White")
add_subscriber(conn, 17542, "Bobby", "Ball")
[mysql@fab1 myfab]$ python add_subs_ha.py
[mysql@fab1 myfab]$ mysql -h 192.168.56.103 -P3306 -u root -e "select * from
test.subscribers"
+--------+------------+-----------+
| sub_no | first_name | last_name |
+--------+------------+-----------+
| 72 | Billy | Fish |
| 500 | Billy | Joel |
| 1500 | Arthur | Askey |
| 5000 | Billy | Fish |
| 15000 | Jimmy | White |
| 17542 | Bobby | Ball |
+--------+------------+-----------+
Copyright © 2014, Oracle y/o sus filiales. Todos los derechos reservados. Página 17Luego los datos pueden ser recuperados (tenga en cuenta que el parámetro mode para la conexión se establece
en fabric.MODE_READONLY y el conector sabe que puede establecer un balance de los requisitos a través de
cualquier servidor MySQL en el grupo HA).
mysql@fab1 myfab]$ cat read_table_ha.py
import mysql.connector
from mysql.connector import fabric
def find_subscriber(conn, sub_no):
conn.set_property(group="group_id-1", mode=fabric.MODE_READONLY)
cur = conn.cursor()
cur.execute(
"SELECT first_name, last_name FROM subscribers "
"WHERE sub_no = %s", (sub_no, )
)
for row in cur:
print row
conn = mysql.connector.connect(
fabric={"host" : "localhost", "port" : 32274, "username": "admin",
"password" : "admin"},
user="root", database="test", password="",
autocommit=True
)
find_subscriber(conn, 72)
find_subscriber(conn, 500)
find_subscriber(conn, 1500)
find_subscriber(conn, 5000)
find_subscriber(conn, 15000)
find_subscriber(conn, 17542)
[mysql@fab1 myfab]$ python read_table_ha.py
(u'Billy', u'Fish')
(u'Billy', u'Joel')
(u'Arthur', u'Askey')
(u'Billy', u'Fish')
(u'Jimmy', u'White')
(u'Bobby', u'Ball')
Tenga en cuenta que si los servidores secundarios no tienen el mismo rendimiento pueden sesgar la proporción
de la cantidad de lecturas que son enviadas a cada uno mediante el comando mysqlfabric server
set_weight si se especifica un valor entre 0 y 1 (la predeterminación es 1 para todos los servidores). Además,
el comando mysqlfabric server set_mode se puede utilizar para especificar si el primario debe recibir solo
las operaciones de lectura (READ_WRITE) o solo las operaciones de escritura (WRITE_ONLY).
Debido a que la duplicación de los esclavos no es simultánea, no se puede garantizar que sus operaciones de
escritura recuperen los últimos datos comprometidos. Si es esencial que la operación de escritura sea
completamente consistente con todas las transacciones comprometidas se debe establecer el modo
fabric.MODE_READWRITE.
Para ser breve, estos ejemplos de código no contienen manejo de errores, para una aplicación real el código
debe lidiar con cualquier error de la base de datos de manera apropiada.
La próxima sección describe cómo esta configuración se puede extender para agregar escalabilidad con la
partición de los datos en la tabla (y puede ser omitida si no es necesario).
Copyright © 2014, Oracle y/o sus filiales. Todos los derechos reservados. Página 186.2 Agregar escalabilidad con particionamiento
El ejemplo en esta sección se construye sobre el anterior y se agregan
más servidores para escalar la capacidad y el rendimiento de las
operaciones de lectura/escritura de la base de datos. El primer paso es
crear un nuevo grupo (que se denomina global-group en este
ejemplo), el grupo global es un grupo especial HA que cumple dos
funciones importantes:
Los cambios en los esquemas de datos se aplican al grupo
global y desde allí se pueden duplicar para cada uno de los otros
grupos HA
Si hay tablas que contienen datos que deben ser duplicados para
todos los grupos HA (antes de que sean particionados) se
realizarán inserciones, actualizaciones o eliminaciones en el
grupo global y luego serán duplicadas en otros. Esas tablas se
denominan tablas globales.
Figura 7 ilustra cómo se verá la configuración una vez que el grupo global
se haya creado.
El grupo global se define y está rellenado con servidores MySQL y luego
un primario se promueve en los siguientes pasos:
[mysql@fab1]$ mysqlfabric group create global-group
Procedure :
{ uuid = 5f07e324-ec0a-42b4-98d0-46112f607143,
finished = True,
success = True,
return = True,
activities = Figura 7 Adición de un grupo global
}
[mysql@fab1 ~]$ mysqlfabric group add global-group\
192.168.56.102:3316
Procedure :
{ uuid = ccf699f5-ba2c-4400-a8a6-f951e10d4315,
finished = True,
success = True,
return = True,
activities =
}
[mysql@fab1 ~]$ mysqlfabric group add global-group \
192.168.56.102:3317
Procedure :
{ uuid = 7c476dda-3985-442a-b94d-4b9e650e5dfe,
finished = True,
success = True,
return = True,
activities =
}
[mysql@fab1 ~]$ mysqlfabric group add global-group \
192.168.56.102:3318
Procedure :
{ uuid = 476fadd4-ca4f-49b3-a633-25dbe0ffdd11,
finished = True,
success = True,
return = True,
activities =
}
Copyright © 2014, Oracle y/o sus filiales. Todos los derechos reservados. Página 19[mysql@fab1 ~]$ mysqlfabric group promote global-group
Procedure :
{ uuid = e818708e-6e5e-4b90-aff1-79b0b2492c75,
finished = True,
success = True,
return = True,
activities =
}
[mysql@fab1 ~]$ mysqlfabric group lookup_servers global-group
Command :
{ success = True
return = [
{'status': 'PRIMARY', 'server_uuid': '56a08135-d60b-11e3-b69a-0800275185c2',\
'mode': 'READ_WRITE', 'weight': 1.0, 'address': '192.168.56.102:3316'}, \
{'status': 'SECONDARY', 'server_uuid': '5d5f5cf6-d60b-11e3-b69b-0800275185c2', \
'mode': 'READ_ONLY', 'weight': 1.0, 'address': '192.168.56.102:3317'}, \
{'status': 'SECONDARY', 'server_uuid': '630616f4-d60b-11e3-b69b-0800275185c2', \
'mode': 'READ_ONLY', 'weight': 1.0, 'address': '192.168.56.102:3318'}]
activities =
}
Como se creó una tabla de aplicación dentro del grupo original HA, eso necesitará que se copie al nuevo grupo
global:
mysql@fab1 myfab]$ mysqldump -d -u root --single-transaction -h 192.168.56.102 -P3306 \
--all-databases > my-schema.sql
[mysql@fab1 myfab]$ mysql -h 192.168.56.102 -P3317 -u root -e 'reset master'
[mysql@fab1 myfab]$ mysql -h 192.168.56.102 -P3317 -u root < my-schema.sql
[mysql@fab1 myfab]$ mysql -h 192.168.56.102 -P3317 -u root -e 'show create table
test.subscribers'
+-------------+------------------------------..-+
| Table | Create Table .. |
+-------------+------------------------------..-+
| subscribers | CREATE TABLE `subscribers` (
`sub_no` int(11) DEFAULT NULL,
`first_name` char(40) DEFAULT NULL,
`last_name` char(40) DEFAULT NULL
) ENGINE=InnoDB DEFAULT CHARSET=latin1 |
+-------------+------------------------------..-+
Una asignación de partición es una entidad que se utiliza para definir cómo se deben particionar determinadas
tablas entre un conjunto de grupos HA. Es posible tener múltiples asignaciones de partición pero en este
ejemplo, se utilizará uno solo. Al definir la asignación de partición, hay dos parámetros clave:
El tipo de asignación puede ser HASH o RANGE
El grupo global que será utilizado
Los comandos a continuación definen la asignación e identifican el número de índice que se asigna a esta
asignación (en este ejemplo, 3) de hecho el mismo índice se recupera de dos maneras diferentes: con la
utilización del comando mysqlfabric y luego al leer los datos directamente desde el almacén de estado:
[mysql@fab1 ~]$ mysqlfabric sharding create_definition HASH global-group
Procedure :
{ uuid = 78ea7209-b073-4d03-9d8b-bda92cc76f32,
finished = True,
success = True,
return = 1,
activities =
}
[mysql@fab1 ~]$ mysqlfabric sharding list_definitions
Command :
{ success = True
return = [[3, 'HASH', 'global-group']]
Copyright © 2014, Oracle y/o sus filiales. Todos los derechos reservados. Página 20activities =
}
[mysql@fab1 ~]$ mysql -h 127.0.0.1 -P3306 -u root \
-e 'SELECT * FROM fabric.shard_maps'
+------------------+-----------+--------------+
| shard_mapping_id | type_name | global_group |
+------------------+-----------+--------------+
| 1 | HASH | global-group |
+------------------+-----------+--------------+
El próximo paso es definir las columnas de qué tablas deben utilizarse como la clave de partición (el valor en el
cual la función HASH se ejecuta o se compara con el RANGE definido). En este ejemplo, solo se ha particionado
una tabla (la tabla subscribers con la columna sub_no que se utiliza como la clave de partición) pero el
comando puede simplemente ser re-ejecutado para otras tablas. Tenga en cuenta que el identificador para la
asignación de partición (3) se pasa en la línea de comandos:
[mysql@fab1 ~]$ mysqlfabric sharding add_table 1 test.subscribers sub_no
Procedure :
{ uuid = 446aadd1-ffa6-4d19-8d52-4683f3d7c998,
finished = True,
success = True,
return = True,
activities =
}
En este punto, la asignación de partición se ha definido pero no hay particiones que se hayan creado por lo que
el siguiente paso es la creación de una única partición y que la partición sea almacenada en el grupo HA
existente group_id-1):
[mysql@fab1]$ mysqlfabric sharding add_shard 1 group_id-1 --state=enabled
Procedure :
{ uuid = 8a351c36-9e80-41fd-a665-f3369aa3b31b,
finished = True,
success = True,
return = True,
activities =
}
[mysql@fab1]$ mysql -h 127.0.0.1 -P3306 -u root -e 'select * from fabric.shards'
+----------+------------+---------+
| shard_id | group_id | state |
+----------+------------+---------+
| 1 | group_id-1 | ENABLED |
+----------+------------+---------+
Copyright © 2014, Oracle y/o sus filiales. Todos los derechos reservados. Página 21También puede leer
