mysql fabric guía para administrar mysql alta ... · pdf fileesfuerzos en la...

Copyright © 2014, Oracle y/o sus filiales. Todos los derechos reservados.

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. Página 2

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


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.


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 command-line-interface (documentado en el manual de referencia

1) 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 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

Figura 1 Alta disponibilidad superpuesta

http://dev.mysql.com/doc/mysql-utilities/en/fabric.html



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 MySQL, consulte el informe de duplicación

1.

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/

http://www.mysql.com/why-mysql/white-papers/mysql-replication-introduction

http://www.mysql.com/why-mysql/white-papers/mysql-replication-introduction/


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 simultánea es únicamente posible con MySQL Cluster

1 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 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/

Figura 3 MySQL Fabric implementa HA

http://www.mysql.com/products/cluster/

http://www.mysql.com/products/cluster/


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 lugar a que esas filas estén en la misma partición, lo 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.

Figura 4 MySQL Fabric implementa HA y el particionamiento


3 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

Se pueden encontrar más detalles sobre otras soluciones en la guía MySQL para soluciones de alta disponibilidad1.

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

http://www.mysql.com/why-mysql/white-papers/mysql-guide-to-high-availability-solutions/

http://www.mysql.com/why-mysql/white-papers/mysql-guide-to-high-availability-solutions


4 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


6 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 en MySQL Fabric, que agrega alta disponibilidad y escalabilidad a MySQL

1. Además, si solo se requiere HA esto

está documentado en MySQL Fabric, agregar alta disponibilidad a MySQL2 y si solo se requiere escalabilidad

MySQL Fabric, agregar escalabilidad a MySQL3.

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

http://www.clusterdb.com/mysql-fabric/mysql-fabric-adding-high-availability-and-scaling-to-mysql

http://www.clusterdb.com/mysql-fabric/mysql-fabric-adding-high-availability-to-mysql

http://www.clusterdb.com/mysql-fabric/mysql-fabric-add-scaling-to-mysql





El 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/ \ --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

Figura 6 Grupo HA único


[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

Se pueden encontrar más detalles sobre estos parámetros de configuración en la documentación de MySQL Fabric1.

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

http://dev.mysql.com/doc/mysql-utilities/1.4/en/fabric-configuration-file.html

http://dev.mysql.com/doc/mysql-utilities/en/fabric-configuration-file.html


Type '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).


[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.


[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


Last_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


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 | +--------+------------+-----------+


Luego 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).


6.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 = } [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 = }

Figura 7 Adición de un grupo global


[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']]


activities = } [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 | +----------+------------+---------+


En este punto, la base de datos se ha particionado pero no ofrece la escalabilidad debido a que existe una única partición. Los pasos a continuación desarrollan esa configuración en una que contiene dos particiones como se muestra en la Figura 8.

Figura 8 Particionamiento, granja de servidores HA MySQL Fabric

Otro grupo HA (group_id-2) se crea, los tres nuevos servidores se agregan y luego uno de los servidores pasa

a ser primario:

[mysql@fab1 ~]$ mysqlfabric group create group_id-2 Procedure : { uuid = 4ec6237a-ca38-497c-b54d-73d1fa7bbe03, finished = True, success = True, return = True, activities = } [mysql@fab1 ~]$ mysqlfabric group add group_id-2 192.168.56.105:3306 Procedure : { uuid = fe679280-81ed-436c-9b7f-3d6f46987492, finished = True, success = True, return = True, activities = } [mysql@fab1 ~]$ mysqlfabric group add group_id-2 192.168.56.106:3306 Procedure : { uuid = 6fcf7e0c-c092-4d81-9898-448abf2b113c, finished = True, success = True, return = True, activities = } [mysql@fab1 ~]$ mysqlfabric group add group_id-2 192.168.56.107:3306 Procedure : { uuid = 8e9d4fbb-58ef-470d-81eb-8d92813427ae, finished = True,


success = True, return = True, activities = } [mysql@fab1 ~]$ mysqlfabric group promote group_id-2 Procedure : { uuid = 21569d7f-93a3-4bdc-b22b-2125e9b75fca, finished = True, success = True, return = True, activities = }

En este punto, el nuevo grupo de HA existe pero no encuentra el esquema de aplicación y los datos. Antes de asignar una partición al grupo, un reset master debe ser ejecutado en el primario para el grupo (esto es requerido debido a que los cambios se han realizado en ese servidor, para conceder permisos para que uno o varios usuarios se puedan conectar de manera remota). El comando mysqlfabric group lookup_servers se utiliza para comprobar cuál de los tres servidores es el primario en ese momento.

[mysql@fab1 ~]$ mysqlfabric group lookup_servers group_id-2 Command : { success = True return = [ {'status': 'PRIMARY', 'server_uuid': '10b086b5-d617-11e3-b6e7-08002767aedd', \ 'mode': 'READ_WRITE', 'weight': 1.0, 'address': '192.168.56.105:3306'}, \ {'status': 'SECONDARY', 'server_uuid': '5dc81563-d617-11e3-b6e9-08002717142f', \ 'mode': 'READ_ONLY', 'weight': 1.0, 'address': '192.168.56.106:3306'}, \ {'status': 'SECONDARY', 'server_uuid': '83cae7b2-d617-11e3-b6ea-08002763b127', 'mode':

'READ_ONLY', 'weight': 1.0, 'address': '192.168.56.107:3306'}] activities = } [mysql@fab1 myfab]$ mysql -h 192.168.56.105 -P3306 -uroot -e 'reset master'

El paso siguiente es dividir la partición existente al especificar la id de la partición (en este caso 1 que encontramos en la tabla fabric.shards) y el nombre del grupo HA donde se almacenará la nueva partición:

[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 | +----------+------------+---------+ [mysql@fab1]$ mysqlfabric sharding split_shard 1 group_id-2 Procedure : { uuid = 4c559f6c-0b08-4a57-b095-364755636b7b, finished = True, success = True, return = True, activities = }

Antes de ver los cambios en el código de aplicación que se necesitan para hacer frente a los datos particionados, se puede ejecutar una simple prueba para confirmar que los datos existentes de la tabla de hecho se hayan dividido entre las dos particiones:

[mysql@fab1]$ mysql -h 192.168.56.102 -P3306 -uroot -e 'select * from test.subscribers' +--------+------------+-----------+ | sub_no | first_name | last_name | +--------+------------+-----------+ | 500 | Billy | Joel | | 1500 | Arthur | Askey | | 5000 | Billy | Fish | | 17542 | Bobby | Ball | +--------+------------+-----------+

[mysql@fab1]$ mysql -h 192.168.56.107 -P3306 -uroot -e 'select * from test.subscribers'


+--------+------------+-----------+ | sub_no | first_name | last_name | +--------+------------+-----------+ | 72 | Billy | Fish | | 15000 | Jimmy | White | +--------+------------+-----------+

El siguiente ejemplo de código Python añade nuevas filas a la tabla subscribers. Tenga en cuenta que la

propiedad de las tables para la conexión se establece en test.subscribers y la key al valor de la columna

sub_no para esa tabla, es suficiente información para que el conector compatible con Fabric pueda elegir la

partición correcta/el grupo HA y luego el hecho de que la propiedad mode se establece en

fabric.MODE_READWRITE le indica al conector que la transacción debe ser enviada al primario dentro del

grupo HA.

[mysql@fab1 myfab]$ cat add_subs_shards2.py import mysql.connector from mysql.connector import fabric def add_subscriber(conn, sub_no, first_name, last_name): conn.set_property(tables=["test.subscribers"], key=sub_no, 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(tables=["test.subscribers"], scope=fabric.SCOPE_LOCAL) add_subscriber(conn, 22, "Billy", "Bob") add_subscriber(conn, 8372, "Banana", "Man") add_subscriber(conn, 93846, "Bill", "Ben") add_subscriber(conn, 5006, "Andy", "Pandy") add_subscriber(conn, 15050, "John", "Smith") add_subscriber(conn, 83467, "Tommy", "Cannon") [mysql@fab1 myfab]$ python add_subs_shards2.py

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.


El cliente mysql se puede utilizar para confirmar que los datos nuevos también hayan sido divididos entre las

dos particiones/grupos HA.

[mysql@fab1 myfab]$ mysql -h 192.168.56.103 -P3306 -uroot -e 'select * from test.subscribers'

+--------+------------+-----------+ | sub_no | first_name | last_name | +--------+------------+-----------+ | 500 | Billy | Joel | | 1500 | Arthur | Askey | | 5000 | Billy | Fish | | 17542 | Bobby | Ball | | 22 | Billy | Bob | | 8372 | Banana | Man | | 93846 | Bill | Ben | | 15050 | John | Smith | +--------+------------+-----------+ [mysql@fab1 myfab]$ mysql -h 192.168.56.107 -P3306 -uroot -e 'select * from

test.subscribers' +--------+------------+-----------+ | sub_no | first_name | last_name | +--------+------------+-----------+ | 72 | Billy | Fish | | 15000 | Jimmy | White | | 5006 | Andy | Pandy | | 83467 | Tommy | Cannon | +--------+------------+-----------+

El último ejemplo de código de aplicación lee la fila para cada uno de los registros que se han añadido, la clave a tener en cuenta aquí es que la propiedad mode para la conexión se ha establecido en fabric.MODE_READONLY

es por ello que el conector Python compatible con Fabric puede cargar consultas de balance sobre los secundarios dentro de los grupos HA en lugar de enviar todo al primario.

[mysql@fab1 myfab]$ cat read_table_shards2.py import mysql.connector from mysql.connector import fabric def find_subscriber(conn, sub_no): conn.set_property(tables=["test.subscribers"], key=sub_no, 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" : 32774, "username": "admin",

"password" : "admin"}, user="root", database="test", password="", autocommit=True ) find_subscriber(conn, 22) find_subscriber(conn, 72) find_subscriber(conn, 500) find_subscriber(conn, 1500) find_subscriber(conn, 8372) find_subscriber(conn, 5000) find_subscriber(conn, 5006) find_subscriber(conn, 93846) find_subscriber(conn, 15000)


find_subscriber(conn, 15050) find_subscriber(conn, 17542) find_subscriber(conn, 83467) [mysql@fab1 myfab]$ python read_table_shards2.py (u'Billy', u'Bob') (u'Billy', u'Fish') (u'Billy', u'Joel') (u'Arthur', u'Askey') (u'Banana', u'Man') (u'Billy', u'Fish') (u'Andy', u'Pandy') (u'Bill', u'Ben') (u'Jimmy', u'White') (u'John', u'Smith') (u'Bobby', u'Ball') (u'Tommy', u'Cannon')

7 Prácticas operativas recomendadas

La alta disponibilidad no es únicamente una función de la tecnología subyacente sino también los procedimientos operativos bien establecidos, probados y administrados por un equipo de operaciones altamente cualificado. Los analistas de la industria estiman que el 80 % del tiempo de inactividad es el resultado de “las personas y los procesos”, por lo que la importancia de las buenas prácticas operativas no debe ser subestimada.

Oracle ofrece una gama de herramientas y servicios que les permiten a los usuarios de MySQL lograr la excelencia operativa y entregar en contra de sus SLA comprometidos.

7.1 Oracle University

La capacitación de los equipos operativos y administrativos reduce el riesgo del error humano que puede dar como resultado interrupciones accidentales al sistema. Oracle University ofrece una amplia gama de capacitación MySQL desde cursos introductorios (es decir, MySQL Essentials, MySQL DBA, etc.) hasta certificaciones avanzadas como la alta disponibilidad MySQL y MySQL Cluster Administration. También es posible definir los planes personalizados de capacitación para entregar en el sitio del cliente.

Usted puede obtener más información acerca del entrenamiento MySQL de Oracle University1.

7.2 Consultoría MySQL

Para garantizar el cumplimiento de las prácticas recomendadas desde la fase de diseño inicial de un proyecto hasta la implementación y la mantención, los usuarios pueden contratar consultores de los servicios profesionales MySQL de Oracle. Estos compromisos ayudan en la optimización de la arquitectura y el aumento de la eficiencia operativa y se brindan de manera remota o in situ.

Oracle ofrece una gama completa de servicios de consultoría desde la arquitectura y el diseño a través de la alta disponibilidad, la duplicación y la agrupación en clústeres. Más información acerca de los servicios de consultoría de MySQL de Oracle

2.

1 http://www.mysql.com/training/ 2 http://www.mysql.com/consulting/

http://www.mysql.com/training/

http://www.mysql.com/consulting/


http://www.mysql.com/training/



7.2.1 MySQL Enterprise Edition y MySQL Cluster Carrier Grade Edition (CGE)

Las ediciones comerciales de MySQL ofrecen el conjunto integral de la producción de MySQL, copia de seguridad, vigilancia, modelado, desarrollo y herramientas de administración de modo que las organizaciones puedan alcanzar los más altos niveles de disponibilidad, rendimiento y seguridad.

Los componentes clave de MySQL Enterprise Edition y MySQL Cluster CGE se analizan a continuación.

7.2.1.1 Soporte global 24 horas al día, 7 días a la semana

MySQL ofrece acceso 24 horas al día, 7 días a la semana, 365 días al año al equipo de soporte MySQL de Oracle, el cual es atendido por expertos en base de datos dispuestos a ayudar con los problemas técnicos más complejos, con acceso directo al equipo de desarrollo MySQL. Premier Support de Oracle le proporciona:

Soporte telefónico y en línea 24 horas al día, 7 días a la semana, 365 días del año

Diagnóstico rápido y solución a problemas complejos

Incidentes ilimitados

Corrección urgente de emergencia

Acceso a la base de conocimientos MySQL de Oracle

Servicios de soporte consultivo

Los partners del equipo de soporte con clientes en el análisis y la remediación de los problemas que causan interrupciones, conducen a la resolución más rápida de los problemas y si es necesario, genera las correcciones urgentes para restablecer el servicio. Este nivel de asistencia ofrece importantes beneficios para HA sobre la comunidad o entornos autónomos.

El acceso a la base de conocimientos de prácticas recomendadas está incluido dentro los acuerdos de soporte MySQL. La base de conocimientos ofrece más conocimiento sobre cómo configurar, aprovisionar y administrar entornos MySQL altamente disponibles.

Más información acerca de los servicios de soporte de MySQL de Oracle1.

7.2.1.2 MySQL Enterprise Monitor

Durante las operaciones normales, el monitoreo de la infraestructura es clave para mantener la alta disponibilidad y puede ayudar a detectar problemas ANTES de que ocurran. MySQL Enterprise Monitor proporciona visualizaciones rápidas del estado de las base de datos, monitorea continuamente los servidores MySQL y alerta sobre problemas potenciales antes de que impacten en el sistema.

MySQL Enterprise Monitor hace un seguimiento automático de cientos de variables MySQL para analizar el estado actual. Un motor sofisticado basado en reglas alerta a los administradores cuando los parámetros exceden los límites definidos para que las operaciones de desarrollo y los equipos DBA puedan evitar de manera proactiva los tiempos de inactividad o la degradación del rendimiento.

Se alertan a los administradores de manera inmediata si ocurre una interrupción y se presentan con información de diagnóstico para acelerar la remediación del problema y restaurar rápidamente la disponibilidad del servicio.

MySQL Enterprise Monitor también almacena datos históricos de estados MySQL para que el análisis de los problemas se simplifique.

Más información acerca de MySQL Enterprise Monitor2.

1 http://www.mysql.com/support/ 2 http://www.mysql.com/products/enterprise/monitor.html

http://www.mysql.com/support/

http://www.mysql.com/products/enterprise/monitor.html

http://www.mysql.com/support/

http://www.mysql.com/products/enterprise/monitor.html


7.2.1.3 MySQL Enterprise Backup

Las copias de seguridad de base de datos son procesos bien establecidos en los entornos de producción. En función de la técnica utilizada, las operaciones de copia de seguridad pueden afectar los servicios actuales de distintas maneras:

Aumento de la carga del servidor, rendimiento que impacta la producción de consultas

El bloqueo de operaciones de escritura, limita el servicio a consultas de sólo lectura durante el proceso de copia de seguridad

Inactividad completa (planeada) durante la copia de seguridad.

Evidentemente, para los servicios HA ninguna de estas es aceptable. Una copia de seguridad completa en línea que no consume los recursos de servidor MySQL es entonces la opción correcta para obtener HA.

MySQL Enterprise Backup funciona en línea “urgente”, sin bloquear las copias de seguridad de las base de datos MySQL. Se pueden llevar a cabo copias de seguridad completas en todos los datos InnoDB, mientras que MySQL está en línea sin interrumpir las consultas o las actualizaciones. Además, las copias de seguridad son compatibles cuando los datos que cambiaron han sido copiados. También las copias de seguridad parciales son compatibles cuando determinadas tablas o espacios de tablas necesitan ser capturados.

MySQL Enterprise Backup restaura los datos desde una copia de seguridad completa con la compatibilidad anterior completa. Consistent Point-in-Time Recovery (PITR) permite a DBA realizar la restauración en un tiempo específico.

Más información acerca de MySQL Enterprise Backup1.

7.2.1.4 Seguridad MySQL Enterprise

La seguridad MySQL Enterprise proporciona módulos de autenticación externos listos para utilizar para integrar fácilmente a MySQL con las infraestructuras de seguridad existentes que incluyen PAM y Windows Active Directory. Los usuarios MySQL se pueden autenticar si utilizan Pluggable Authentication Modules (“PAM”) o servicios de sistemas operativos nativos de Windows.

Más información acerca de la seguridad MySQL Enterprise2.

7.2.1.5 Auditoría MySQL Enterprise

La auditoría MySQL Enterprise le permite añadir de forma rápida y sin problemas de cumplimiento de auditoría basado en políticas para aplicaciones nuevas y existentes. Puede activar dinámicamente el registro de actividades de nivel de usuario, aplicar políticas basadas en la actividad, administrar los archivos de registro de auditoría e integrar la auditoría de MySQL con Oracle y soluciones de terceros.

Más información acerca de la auditoría MySQL Enterprise3.

1 http://www.mysql.com/products/enterprise/backup.html 2 http://www.mysql.com/products/enterprise/security.html 3 http://www.mysql.com/products/enterprise/audit.html

http://www.mysql.com/products/enterprise/backup.html

http://www.mysql.com/products/enterprise/security.html

http://www.mysql.com/products/enterprise/audit.html

http://www.mysql.com/products/enterprise/backup.html

http://www.mysql.com/products/enterprise/security.html

http://www.mysql.com/products/enterprise/audit.html


8 Conclusión

MySQL Fabric es un marco extensible para la administración de granjas de servidores MySQL y permite que MySQL Connectors obtengan transacciones y consultas sobre el servidor más apropiado mientras que ocultan la topología de la granja de servidores desde la aplicación.

El intento es que los desarrolladores se puedan enfocar en actividades de alto valor como agregar nuevas funciones a las aplicaciones en lugar de dedicar tiempo al arreglo de la plataforma, que ahora lo puede manejar MySQL Fabric.

Las primeras aplicaciones compatibles con MySQL Fabric son la alta disponibilidad (basada en la duplicación MySQL) y el particionamiento basado en la escalabilidad. Con el tiempo esperamos añadir nuevas opciones para estas aplicaciones (por ejemplo, tecnologías alternativas HA), así como también aplicaciones completamente nuevas. Esperamos saber qué les gustaría agregar a los usuarios como así también qué desean para ellos mismos.

9 Recursos adicionales

MySQL Fabric http://www.mysql.com/products/enterprise/fabric.html

MySQL Fabric Documentation http://dev.mysql.com/doc/mysql-utilities/en/fabric.html

Tutoriales detallados de MySQL Fabric:

o MySQL Fabric, agregar alta disponibilidad a MySQL http://www.clusterdb.com/mysql-fabric/mysql-fabric-adding-high-availability-to-mysql

o MySQL Fabric, agregar escalabilidad a MySQL http://www.clusterdb.com/mysql-fabric/mysql-fabric-add-scaling-to-mysql

o MySQL Fabric, agregar alta disponibilidad y escalabilidad a MySQL http://www.clusterdb.com/mysql-fabric/mysql-fabric-adding-high-availability-and-scaling-to-mysql

Guía para las soluciones de alta disponibilidad MySQL http://www.mysql.com/why-mysql/white-papers/mysql-guide-to-high-availability-solutions/

Particionamiento automático y alta disponibilidad con MySQL Fabric, Repetición del Seminario web http://www.mysql.com/news-and-events/web-seminars/automated-sharding-and-high-availability-with-mysql-fabric/

http://www.mysql.com/products/enterprise/fabric.html





http://www.mysql.com/why-mysql/white-papers/mysql-guide-to-high-availability-solutions/

http://www.mysql.com/news-and-events/web-seminars/automated-sharding-and-high-availability-with-mysql-fabric/

http://www.mysql.com/news-and-events/web-seminars/automated-sharding-and-high-availability-with-mysql-fabric/

mysql fabric guía para administrar mysql alta ... · pdf fileesfuerzos en la...

Documents