ESCALAMIENTO Y REPLICACIÓN DE LA BASE DE DATOS MYSQL™ PARA

NEGOCIOS DE ALTO CRECIMIENTO Nick Kloski, Grupo de Soluciones Ingenieriles Sun BluePrints™ Online

Parte No 820-6824-10 Revisión 1.0, 11/4/08

Sun Microsystems, Inc.

1

MySQL Database Scale-Out and Replication

Sun Microsystems, Inc.

Replicación y Escalamiento de la Base de Datos MySQL Está ampliamente reconocido que MySQL es el software de base de datos más popular en el mundo. Desde sus inicios en 1995, ha habido 11 millones de instalaciones del producto alrededor del mundo en una vasta variedad de mercados. En la actualidad existen más instalaciones de MySQL en uso que de cualquier otra arquitectura de base de datos. Desde las compañías principiantes que esperan ser la siguiente estrella Web 2.0 hasta las grandes empresas globales, la arquitectura de la base de datos MySQL ha probado ser flexible, extensible, escalable, y más que competente para cumplir con los roles de alta capacidad de base de datos en muchos escenarios diferentes. La estructura de la arquitectura MySQL se ofrece de forma gratuita para cualquiera que la descargue y use, ayudando a hacer que el software de MySQL sea popular en su uso en una gran variedad de roles. Sin embargo, la facilidad con la cual las instancias pueden ser desplegadas, frecuentemente presenta retos: Con el tiempo, las compañías pueden encontrarse así mismas tratando con múltiples casos MySQL equivocados y necesitan tomar el reto de cómo escalar sus instalaciones MySQL inteligentemente tanto en el escalamiento como en la recuperación en caso de apagones. Este documento especifica las principales maneras de cómo las instalaciones MySQL pueden escalar para cumplir con las demandas crecientes del usuario, mientras que al mismo tiempo provee la flexibilidad y la facilidad de uso que esas solas instalaciones ofrecen.

Introducción al Escalamiento El uso de MySQL no le cuesta nada a la estructura central del sistema de la base de datos. Compañías de todas dimensiones son alentadas a descargar y poner a producir instancias MySQL de manera tan amplia y grande como éstas lo deseen. Debido a esto, muchas veces MySQL es usado para hacer una demostración inicial de la prueba del concepto como respaldo y almacenamiento de datos de varios proyectos. Al mismo tiempo que esos proyectos demuestran ser factibles, la arquitectura MySQL es típicamente más que capaz de manejar la demanda inicial generada por aplicación asociada. Sin embargo, en algún punto, las demandas de la base del usuario requieren que la base de datos MySQL escale para proveer las veces de respuesta que exceden las capacidades del hardware del servidor fundamental. Es en este punto que la arquitectura MySQL necesita extenderse más allá del servidor inicial para dar más capacidad para cumplir con la demanda. Es aquí que la planeación inteligente para escalar no solamente resolverá los problemas manteniendo un tiempo de respuesta para los usuarios finales, sino que también puede proporcionar recuperación en contra de los apagones que de otra manera detendrían el funcionamiento de la base de datos.

2

MySQL Database Scale-Out and Replication

Sun Microsystems, Inc.

Definición del Escalamiento Cuando los Administradores de la Base de Datos (DBAs por sus siglas en inglés) hablan acerca de escalamiento, se están refiriendo a ser capaces de servir un número creciente de requerimientos contra de la base de datos. El desempeño específico de un requerimiento una vez que este llega a la base de datos es afectado por dichos factores como aplicar la lógica y destacar el poder del CPU, la densidad de memoria y la interconexión I/O. Nota – Una discusión acerca de la afinación específica de la base de datos está más allá de la extensión de este documento. En su lugar, este documento se enfoca en las consideraciones de nivel empresarial y en la escalabilidad del servidor completo.

Figura 1. Escalamiento de lectura de la base de datos básica Este enfoque se opone a otro método de escalamiento: escala en ascenso (scale up). En un escenario de escala en ascenso, el hardware del servidor existente es incrementado, por lo tanto es capaz de servir a más requerimientos por medio de un incremento de la energía del back-end. Existen ventajas en ambos métodos: Escala en ascenso (scale-up) (también llamada Escalamiento Vertical) - Debe operar en un hardware más costoso para permitir escalamiento. - En ocasiones corre software propietario para permitir escalamiento. - Exclusiva de una plataforma hardware/software. - Una vez que se llega al límite de una plataforma hardware específica, el servidor completo debe ser reemplazado (fork lift upgrade). Escalamiento (scale-out) (también llamada Escalamiento Horizontal) - Terminada con un artículo hardware Intel/AMD. - Corre en software/sistemas operativos de código abierto. - Puede apalancar la independencia de la plataforma para permitir a las instalaciones escaladas MySQL operar sin parar en una variedad de servidores.

3

MySQL Database Scale-Out and Replication

Sun Microsystems, Inc.

- Añadir servidores convenientes permite una experiencia sustentada y mejorada al usuario final. El servidor MySQL no fue diseñado originalmente para operar en servidores costosos y enormemente complejos. Está es diseñado para conectar fácilmente pequeños servidores juntos, incluyendo tecnologías de replicación que permiten un rápido escalamiento de las bases de datos en un hardware de bajo costo. El resto de este documento se enfoca en el escalamiento MySQL y en la replicación.

Componentes del Escalamiento de la Base de Datos MySQL Los siguientes componentes pueden ser utilizados para implementar el escalamiento en una arquitectura de base de datos MySQL: * Replicación MySQL La definición de la Replicación MySQL es simple: la duplicación de datos cambia a más de un sitio. La replicación puede ser tanto sincrónica como asincrónica. Con una replicación sincrónica, los nuevos datos que entren a una arquitectura de escalamiento MySQL pueden ser aceptados mediante y por escrito a todos los servidores de la base de datos al mismo tiempo. En contraste, con la replicación asincrónica los cambios y los nuevos datos van primero a un servidor Master o principal (le llamaremos maestro), y un momento más tarde son enviados a servidores Slave o secundarios (los que llamaremos esclavos). * Cluster MySQL El producto Cluster MySQL es una base de datos que no comparte nada en la memoria que permite a una empresa incrementar tanto en redundancia como en capacidad adhiriéndose a la idea de más copias en más sitios. Añadiendo nodos de información, la base de datos fundamental opera en más servidores físicos y puede ser accesada correspondientemente por más clientes. Añadiendo la Replicación MySQL al Clustering puede ser utilizada para lograr la redundancia geográfica (para tales propósitos como recuperación de desastres y respaldos) tomando un cluster corriendo de múltiples servidores y replicando ese cluster a algún otro lugar geográfico. * Linux Heartbeat El sistema operativo Linux ofrece una pequeña pieza del software que juega un rol importante en el Clustering MySQL. Aunque no es requerido, al añadir el heartbeat en el Cluster MySQL, el sistema operativo funciona mano-a-mano con la base de datos para proporcionar notificación al otro lado de un cluster cuando uno de los lados se apaga, debido a la falla del hardware u otro evento importante. El Linux Heartbeat maneja los controles IP y notifica al entorno MySQL que una falla ha sucedido y que un proceso de eliminación de falla debe iniciarse. * Balanceo de Carga Existen varios métodos que los DBA puede utilizar para que de una manera inteligente enruten los requerimientos entrantes del usuario a una arquitectura de escalamiento MySQL. A través del uso de los balanceadores de carga, los requerimientos entrantes del usuario se enrutan a la base de datos MySQL apropiada. En un escenario de escalamiento MySQL, el balanceador de carga puede estar basado tanto en un hardware como en un software.

4

MySQL Database Scale-Out and Replication

Sun Microsystems, Inc.

Un ejemplo del balance basado en un hardware es un enrutador inteligente que puede interceptar los requerimientos entrantes y sabe a que servidor MySQL enviarlos. El balanceo de carga basado en un software es también llamado solicitud lógica. La solicitud final se construyó en la solicitud misma para enrutar el requerimiento al servidor MySQL correcto. * Dispositivo en Bloque Replicado Distribuido El Dispositivo en Bloque Replicado Distribuído (DRBD por sus siglas en inglés) como el nombre lo sugiere, crea una replicación de nivel de bloque en diferentes servidores físicos. El software DRBD es el principal componente para habilitar la replicación sincrónica. Además, existen muchos instrumentos de hardware de almacenamiento compartido y agentes de clustering para monitorear a los clusters replicados MySQL pero estos no están cubiertos a profundidad en este documento.

Nota – No todas estas tecnologías están incluídas en la descarga de MySQL Community; algunos servicios pueden requerir pago y/o suscripción a MySQL Enterprise. Ver http://mysql.com/products/enterprise/features.html para información actual en las características incluidas.

El resto de este documento discute estos componentes y describe como estos pueden ser empleados en las arquitecturas de escalamiento MySQL.

Usos Clave para la Replicación MySQL Una combinación de estos componentes puede ser empleada para resolver problemas comunes a muchas implementaciones MySQL. El caso de uso más simple en la replicación es para propósitos puros de respaldo en contra de la falla del servidor maestro. Utilizando un conjunto simple Maestro/Esclavo, la información que es enviada al servidor activo es copiada asincrónicamente a un servidor esclavo y si el servidor activo alguna vez falla, el servidor de replicación puede tomar su lugar. Los escenarios más complejos para la replicación involucran escenarios de Inteligencia de Negocio en donde la base de datos del back-end puede ser replicada a otro servidor sobre el cual las totalmente diferentes técnicas de investigación de datos analíticos pueden ser aplicadas. Las arquitecturas de escalamiento pueden proveer niveles más altos de desempeño y crecimiento flexible. Y las implementaciones de Alta Disponibilidad (HA por sus siglas en inglés) pueden permitir acceso constante ininterrumpido a los recursos de la base de datos, haciendo la implementación recuperable a cualquier apagón de hardware.

Replicación de la Base de Datos MySQL MySQL 5.1, la última versión del software al momento de este escrito, provee un nuevo soporte a una replicación basada en hilera (row). Las versiones previas de MySQL (5.0 e inferiores) apoyaron la replicación basada en declaración (statement). Además, una combinación de la replicación basada en declaración y la basada en hilera pueden ser utilizadas en MySQL 5.1.

5

MySQL Database Scale-Out and Replication

Sun Microsystems, Inc.

La principal diferencia entre una declaración y una hilera para propósitos de replicación es que una declaración es generada a través de un lenguaje de búsqueda o de query estructurado, mientras que en la replicación basada en hilera está basada en los datos no procesados en cada hilera. Antes de la introducción del soporte MySQL 5.1 para la replicación basada en hilera, se debía tener cuidado al usar la replicación basada en la declaración para optimizar totalmente la declaración y evitar el desempeño de los cuellos de botella. Tales problemas de desempeño podían ser generados a través de una estructura de búsqueda ineficiente que solicitaba múltiples datos basados en pequeños resultados, con una búsqueda extendida compleja. En esa etapa, ese tipo de desempeño para regresar una búsqueda con dichas características era inevitable.

Replicación por Declaración versus Replicación por Línea Iniciando en MySQL 5.1, los DBAs tienen la elección de utilizar la replicación basada en la declaración o basada en hileras, o una combinación de las dos. La replicación basada en la declaración es mejor para las aplicaciones que no hacen un uso pesado de las funciones no-determinantes o lo que el sistema llama tal como usuarios SELECTS(). La replicación MySQL basada en la declaración produce pequeños archivos de registro binario y un registro binario puede ser utilizado para auditar la base de datos. Debido al registro binario más eficiente, la replicación basada en declaración puede procesar más transacciones por segundo en muchos casos. Con una replicación basada en hilera, todo (es decir, una hilera completa) puede ser replicado. Muy pocos candados son usados en muchas declaraciones DML tanto en los servidores maestros como en los servidores esclavos utilizando la replicación basada en hilera. Además, la replicación basada en hilera puede resultar en una aplicación más rápida de cambio de datos en los servidores esclavos, especialmente en objetos con llaves primarias.

Interiores de la Replicación MySQL La figura 2 ilustra el proceso de replicación en MySQL, asumiendo un sistema Maestro y Esclavo MySQL. El daemon mysqld en el servidor maestro es el proceso que interactúa con los requerimientos entrantes del usuario. READS Y SELECTS se sirven externamente mientras que los UPDATES son escritos en el disco, pero también escritos en lo que es llamado registro binario o binlog. Este binlog está indexado y llega a ser la base para replicar esas ACTUALIZACIONES en el servidor esclavo. El binlog del servidor maestro es enviado al daemon mysqld en el servidor esclavo, el cual comprende que un evento de replicación tiene que suceder.

6

MySQL Database Scale-Out and Replication

MySQL Master

Sun Microsystems, Inc.

MySQL Slave mysqld

mysqld

I/O Thread updates selects

updates

Replication 1

2

3

4

6

7

SQL Thread

5

data index & binlogs

binlog

data

Figura 2. Interiores de la replicación MySQL Para manejar el flujo del binlog entrante, MySQL envía la replicación binlog a un proceso especial, el thread o hilo I/O, el cual es el responsable de emular un evento de escritura real a ese binlog del servidor esclavo . En el servidor esclavo, este nuevo hilo de replicación (el binlog entrante proveniente del servidor maestro) es transferido a un registro temporal en el servidor esclavo, llamado el binlog relay. El binlog relay es entonces alimentado como un hilo SQL normal a la base de datos en el servidor esclavo, el cual es responsable de dos cosas. El flujo de replicación, lleno de cambios a los datos es escrito a almacenamiento en-disco, y también canalizado al mismo tiempo al registro binario del servidor esclavo. Este binlog del servidor esclavo, si se desea, forma la base para la replicación en cascada para otros servidores. Una vez que existe el binlog en cualquier servidor MySQL, indistintamente de que sea un servidor maestro o esclavo, ese binlog puede ser utilizado para más replicación con otros servidores esclavos. Debido a que los esclavos controlan el proceso de replicación, los esclavos individuales pueden ser conectados y desconectados del servidor sin afectar la operación maestra. También, debido a que cada esclavo recuerda la posición sin el registro binario, es posible que los esclavos sean desconectados, reconectados y después “retomarlos” continuando con la posición registrada. Note sin embargo que en escenarios de failback, se debe tener cuidado para asegurarse que los servidores esclavos se reintegren al grupo de replicación de manera exitosa, y que cualquier cambio hecho a los miembros del grupo en línea sean también replicados, no sólo escrituras continuas.

Topologías de Replicación MySQL Múltiples topologías reciben soporte de la replicación MySQL, como se ha visto en la Figura 3. La replicación de topología más simple es una sóla configuración maestro/esclavo. Las configuraciones con un maestro y múltiples esclavos también reciben soporte.

7

MySQL Database Scale-Out and Replication

Sun Microsystems, Inc.

Topologías más complejas incluyen configuraciones multi-maestras, con característica de dos o más servidores maestros. Mientras estas configuraciones están soportadas, se debe tener cuidado de asegurarse que los espacios de datos no están compartidos entre los servidores maestros. Si el maestro es situado incorrectamente en una configuración multi-maestra, puede ocurrir una sobre-escritura de los datos. Una topología que no está soportada es una configuración multi-fuente, con múltiples maestros actualizando un sólo servidor esclavo.

Master

Slave

Master

Slaves

Supported

Masters

Slave (Multi-Source)

Master

Not Supported Master

Slaves

Slaves

Supported

Master (Multi-Source)

Circular (Multi-Master)

Supported with caution

Figura 3. Topologías de replicación MySQL

Arquitecturas de Escalamiento Básico Con el tiempo, muchas bases de datos necesitan expandirse en su habilidad para responder a los incrementos en los requerimientos de los usuarios. Otros pueden necesitar ser capaces para resistir las fallas del hardware sin funcionar, y buscar soluciones de alta disponibilidad. La replicación MySQL es un medio para ayudar a resolver estos problemas comunes.

Escalamiento (Read Scale-out) El uso más común de las bases de datos es servir información almacenada en la base de datos a los usuarios que están solicitando esos datos. Un problema común en las bases de datos crecientes es la necesidad de ser capaces de servir más lecturas (reads) que escrituras (writes). Esta situación ocurre cuando la solicitud para accesar a la base de datos se vuelve más popular y confunde al hardware originalmente provisto. Por lo tanto, el problema es ser capaz de servir más y más operaciones de lectura mientras que correspondientemente sea capaz de servir ligeramente más operaciones que modifican la base de datos. Este enfoque es llamado escalamiento de lectura (read scaling), y es la forma más común de replicación.

8

MySQL Database Scale-Out and Replication

Sun Microsystems, Inc.

Una arquitectura básica de escalamiento de lectura (read scale-out) es mostrada en la Figura 4. Esta arquitectura añade múltiples servidores que están diseñados para manejar las operaciones READ, y está bien equipada para aplicaciones de lectura intensiva. Todas las escrituras de las bases de datos son servidas por un servidor maestro. La base de datos es replicada en múltiples servidores esclavos, y estos esclavos manejan los requerimientos de lectura.

- Write to one master - Read from many slaves - Perfect for read intensive apps

Load Balancer or Application Logic

Writes and Reads

Master

Reads

Reads

Slave

Slave

Replication

Figura 4. Arquitecura básica de escalamiento de lectura.

Es realmente muy costoso, en términos de procesamiento de la base de datos, hacer una actualización o agregar a la base de datos. Es mucho más fácil provisionar con múltiples operaciones de lectura (READ) en múltiples servidores y permitir que suceda la actualización principal en el servidor Maestro.

Replicación Asincrónica Distinto al clustering, la replicación MySQL envía todas las actualizaciones a la base de datos en el servidor maestro, mientras que las operaciones de lectura impactan cualquier cantidad de servidores esclavos de escalamiento read. Las actualizaciones al servidor maestro están hechas y comprometidas con la base de datos como siempre lo han estado. La replicación asincrónica (de aquí en adelante llamada replicación a menos de que se especifique de otra manera) habilita esas actualizaciones para ser enviadas a cualquier cantidad de servidores esclavos tiempo después en que las actualizaciones son hechas y comprometidas al servidor maestro. Luego entonces, las actualizaciones hechas a la base de datos pueden no estar inmediatamente disponibles a las lecturas hechas en contra de los servidores esclavos. Este efecto puede ser visto en muchos sitios Web de media social, en donde las actualizaciones que un usuario hace son vistas por ese usuario, pero toma algo de tiempo a esas actualizaciones mostrarse a otros usuarios utilizando el mismo sitio. Balanceo de Carga El servidor MySQL incluye las tecnologías de replicación que permiten un rápido escalamiento a las bases de datos en artículos de hardware de bajo costo. La habilidad para conectarse fácilmente a varios servidores más pequeños juntos proveen flexibilidad, como una organización puede utilizar cualquier tipo de objetivos de replicación para resolver un cierto problema. Sin embargo, debido a esta flexibilidad, no existen tecnologías unificadoras en la línea que actúen como servidores generales proxy MySQL para la replicación. En este momento, mientras que varias aplicaciones proxy MySQL están en desarrollo, ninguna ha subido

9

MySQL Database Scale-Out and Replication

Sun Microsystems, Inc.

al nivel de un producto completamente desarrollado. Por ello, la situación principal que una organización necesita considerar cuando se cambia a una arquitectura de escalamiento (scaled-out) es la separación de los requerimientos SELECT/READ/WRITE del usuario entrante para separar a los servidores MySQL. El balanceo de la carga es necesario en una arquitectura de escalamiento de lectura MySQL para separar las acciones del usuario antes que estas lleguen a los servidores escalados de bases de datos back-end. Cuando se cambia a un ambiente replicado, no existe intermediario que haga esto posible. Un balanceador de carga basado ya sea en hardware o software es requerido. Para la solución basada en hardware, el balanceador de carga es una pieza de hardware especializada que está diseñada para leer inteligentemente los requerimientos del usuario entrante e incluye la lógica para enviar esos requerimientos a servidores MySQL específicos en el back-end. El mismo resultado final puede ser completado con un enfoque basado en software. Esto requiere de una modificación de la aplicación misma, de manera que la aplicación sepa acerca de las topologías de replicación existentes en el back-end y en las rutas de los requerimientos READ del usuario de acuerdo con los servidores de sólo-lectura recientemente añadidos.

Partición de Aplicaciones Partición de aplicaciones o sharding, es otra técnica que puede ser considerada para habilitar el escalamiento (scale-out) MySQL. El término shard significa “un pedazo de” y es usado en este contexto para referirse a la distribución de las operaciones escritas, no de lectura (reads).

- Partitioning across multiple databases - Read from many slaves - Higher complexity

Load Balancer or Application Logic

Writes & Reads

ID 1-999

Reads

ID 1000-1999 ID 2000-2999

Replication

Figura 5. Partición de Aplicaciones o sharding. Aunque la replicación de lectura tiene múltiples copias de sólo-lectura de la base de datos, el sharding o la partición de aplicaciones aún tiene múltiples servidores físicos, pero secciones de la base de datos principal están extendidas entre esos servidores (Figura 5). Como un ejemplo, se asume que los usuarios finales de la base de datos están categorizados como userid. En este caso, el despliegue puede ser escalado a tres servidores, con un tercio del rango userid que reside en cada uno de los tres servidores.

10

MySQL Database Scale-Out and Replication

Sun Microsystems, Inc.

Asumiendo que la carga de los usuarios en cualquier momento dado es igualmente distribuida, por lo tanto esos servidores deberían por lo tanto estar solamente 1/3 tan activo como un sólo servidor manejando todas las funciones de la base de datos. En una pura configuración fragmentada, como la mostrada en este ejemplo, una pérdida de cualquier servidor causará un apagón a los usuarios en ese servidor en particular. En un equipo puro de replicación de lectura, la pérdida de un servidor esclavo sólo causará un apagón temporal al usuario final, hasta que el mecanismo de balanceo de la carga envíe a los usuarios desplazados a uno de los servidores remanentes.

Técnicas de Layering Mientras que las técnicas introducidas en este documento pueden ser aplicadas individualmente, también pueden ser aplicadas juntas para dar los beneficios de ambas/todas las estrategias. Por ejemplo: La replicación de lectura a través de los esclavos de replicación ayuda a escalar lecturas (reads) pero es vulnerable para el servidor maestro de tener un apagón (en cuyo caso sólo serán posibles las lecturas). La partición de aplicaciones/sharding ayuda a escalar las escrituras pero es aún más vulnerable al apagón del servidor ya que existen físicamente más servidores (en cuyo caso ninguna lectura o escritura serán posibles en el servidor fallido). Los servidores esclavos de sharding y replicación ofrecen escalabilidad para ambas lecturas y escrituras (en donde aún un apagón del servidor maestro impedirá las actualizaciones para ese servidor pero las LECTURAS aún estarán disponibles). Cuando se piense en acomodar por capas estas técnicas, no hay que considerar a los servidores como el bloque básico para la replicación. Aún para las pequeñas instalaciones, existe a menudo una necesidad de una organización para crear otra copia del equipo completo de la base de datos en otra ubicación para propósitos de Recuperación de Desastre (DR por sus siglas en inglés). Si algo le sucede al principal centro de datos, entonces el centro de datos alterno puede tomar el control. La replicación puede ser utilizada en una redundancia geográfica. Para cualquier arquitectura completa MySQL, esa arquitectura puede, a través de la replicación, ser recreada a otro centro de datos completo. Este proceso es asincrónico, como lo es con replicación normal, pero el centro de datos de recuperación de fallas (failover data center) tendrá una copia razonablemente actualizada de sus datos cuando suceda la falla. Precaución – ¡La Replicación Geográfica de un centro de datos a otro no tiene recuperación de falla automatizada, ni resincronización automática de los datos una vez que su sitio principal está de nuevo en-línea!

Linux Heartbeat El sistema operativo Linux contiene una utilidad heartbeat que permite a dos servidores (o grupos de servidores) utilizar una conexión entre ellos para determinar si cualquiera de los servidores ha encontrado un error y se ha apagado. Esto permite a un grupo de servidores actuar como el grupo principal MySQL y el otro de reserva, listo para recuperar si el principal se apaga.

11

MySQL Database Scale-Out and Replication

Sun Microsystems, Inc.

Un ejemplo de configuración empleando el mecanismo Linux heartbeat es mostrado en la Figura 6. Los mensajes son enviados entre el servidor maestro y el esclavo para determinar si el otro servidor está funcionando. Una dirección virtual IP es utilizada para dirigir los requerimientos entrantes al servidor activo. En este ejemplo, el sistema está operando normalmente y todos los requerimientos enviados a la dirección virtual IP 192.168.0.50 son dirigidos a la dirección privada del servidor maestro de 192.168.0.30. En esta configuración, el grupo de servidores alternos (esclavos) es actualizado por una replicación asincrónica, y por lo tanto tiene un conjunto de datos razonablemente actualizados en caso de una recuperación de falla. Sin embargo, aún se trata de una replicación asincrónica cuando una falla del grupo principal de servidores inicia una recuperación de falla, el grupo servidor de respaldo podría tener escrituras ligeramente desactualizadas ya que las escrituras hechas al servidor maestro podrán no haber sido replicadas en el servidor esclavo.

Linux Heartbeat

Master MySQL Server

Slave MySQL Server

Virtual IP 192.168.0.50

MySQL

Private IP 192.168.0.30

MySQL Asynchronous MySQL Replication

Private IP 192.168.0.40

Figura 6. Linux heartbeat replicación MySQL. Si el servidor maestro falla, el mecanismo Linux heartbeat detecta esto y automáticamente vuelve a mapear la dirección virtual IP utilizada por los clientes a la dirección privada IP del servidor esclavo, como se muestra en la Figura 7. Por lo tanto, los requerimientos del usuario son automática y transparentemente re-enrutados al servidor esclavo en caso de una falla del servidor maestro.

Linux Heartbeat

Master MySQL Server

Slave MySQL Server

Virtual IP 192.168.0.05

MySQL

Private IP 192.180.30

MySQL

Private IP 192.168.0.40

Potential for losing some transaction in a fail-over

Figura 7. Linux heartbeat y replicación MySQL, después de que ocurre la falla. Después de que ocurre una falla y el servicio hace failover hacia el servidor esclavo, los procedimientos necesitan hacer failback al servidor original MySQL maestro después de que la condición de error ha sido resuelta. Muchas veces, el mecanismo de recuperación de falla de los servidores maestros a los servidores replicados/de reserva es bien conocido y probado, pero el proceso de recuperación puede ser más

12

MySQL Database Scale-Out and Replication

Sun Microsystems, Inc.

prolongado y más complejo que lo anticipado. No existe un comando de “replicación de desempeño en reversa” en MySQL y recuperarse esencialmente en una dirección en reversa puede ser complejo algunas veces. La instalación Linux heartbeat típicamente requiere de una conexión serial entre los servidores a implementar. Esta solución es de código abierto y fácil de configurar, haciendo que la implementación y mantenimiento no sean costosos. Una vez implementada, el manejo virtual IP es automático. Configurar la funcionalidad del Linux heartbeat puede ser útil al desplegar grupos de servidores en centros de datos separados. Mientras que la replicación entre estos grupos de servidores no tienen ninguna instalación en la arquitectura MySQL para recuperación de falla automática, el Linux heartbeat puede ser utilizado para implementar la auto-recuperación de falla.

Dispositivo en Bloque Replicado Distribuido (DRBD por sus siglas en Inglés) Los mecanismos de replicación de MySQL pueden ser utilizados para escalar funciones de lectura (READ) y de escritura (write) (UPDATE, INSERT, DELETE). La replicación geográfica también puede ser implementada para proveer alguna seguridad en caso de falla de un grupo completo de servidores. Sin embargo aún existen dos principales obstáculos, con los enfoques mencionados hasta este punto en el documento: * La replicación asincrónica aumenta la posibilidad una versión menos actualizada de la base de datos MySQL sirviendo clientes en caso de una recuperación de falla. * Los tiempos de recuperación para regresarse a la topología de la base de datos original es algo complejo. Diferente a la replicación asincrónica, la característica del Dispositivo de Bloqueo Replicado Distribuido en MySQL ayuda a resolver estos problemas teniendo todas las copias de todos los datos en todos los servidores completamente actualizados. Entonces, si ocurre una falla en el servidor maestro, todos los servidores esclavos han actualizado copias de la base de datos disponible. El acrónimo DRBD puede ser definido como: * Distribuido (D) –Corre a través de múltiples servidores. * Replicado (R) –Ejecuta los deberes de replicación de la base de datos. * Bloque (B) –La replicación sucede a un nivel de bloque/hardware, no al nivel de la base de datos. * Dispositivo –(D) Implementa un instrumento conductor que ejecuta la sincronización, no al nivel de la base de datos. La característica DRBD de MySQL permite la replicación sincrónica de los bloques de datos sustentando la base de datos misma. El DRBD corre sobre redes IP estándar entre los servidores (sin necesidad de un hardware especial), con recuperación de falla y direcciones virtuales IP administradas por el programa Linux heartbeat (Figura 8). El DRBD puede ofrecer gran desempeño debido a que la complejidad de cualquier base de datos está escondida del DRBD – El DRBD se ocupa solamente del bloque fundamental de datos y no de la complejidad de la base de datos. DRBD introduce un poco más de complejidad durante la fase de instalación pero eventualmente, los resultados de replicación y recuperación compensan de manera superior todos los pasos de la instalación inicial.

13

MySQL Database Scale-Out and Replication

Active Server

IP Engagement

Sun Microsystems, Inc.

Passive Server

Virtual IP 192.168.0.50 MySQL DRBD

Private IP 192.168.0.30

MySQL Synchronous Block Replication

DRBD

Private IP 192.168.0.40

Figura 8 Linux heartbeat y dispositivo en bloque replicado distribuido (DRBD). La sincronización DRBD actualiza ambos servidores así que en caso de una recuperación de falla del servidor de la base de datos no existen copias desactualizadas de la base de datos. También, cuando la causa de la falla del servidor ha sido resuelta, el DRBD copiará, a nivel de bloque, la base de datos corriente o en función de regreso al servidor maestro, actualizando así todas las bases de datos. Esta función permite a la recuperación ser mucho menos compleja y consumir menos tiempo que de otra manera hubiera tomado lugar en un escenario tradicional de replicación. Debido a que la base de datos es actual en todo momento, los administradores de la base de datos no se tienen que preocupar por lo intrincado de mezclar dos bases de datos de regreso juntas.

DRBD y Replicación Mientras que el DRBD puede ser utilizado como una función aislada de la replicación MySQL, la fuerza real en esta tecnología es vista en combinación con otras características MySQL. Utilizando el DRBD conjuntamente con la replicación de lectura (read) (Figura 9) permite a los servidores de la base de datos (los cuales tienen típicamente características más costosas desde una perspectiva de hardware) sincronizadamente registrar requerimientos de escritura, mientras que los esclavos de replicación de lectura sirven al grueso de las operaciones entrantes READ. Administrado por la función Linux heartbeat, el único servidor activo de la base de datos puede sufrir una falla, el servidor pasivo se volverá activo, y no existe pérdida de ningún dato de los usuarios, ni los usuarios experimentan un apagón.

14

MySQL Database Scale-Out and Replication

Sun Microsystems, Inc.

IP Management

Active Server

Passive Server

Virtual IP 192.168.0.50

MySQL

MySQL

DRBD

DRBD

Private IP 192.168.0.30

Private IP 192.168.0.40

MySQL

Figura 9. DRBD con replicación MySQL.

Clusters DRBD, Aplicación de Partición y Replicación Un ejemplo final reúne todas las características y los casos de uso discutidos previamente dentro de una topología. La figura 10 muestra una caracterización de topología DRBD, partición de aplicaciones, y replicación. Utilizando DRBD para coherencia del servidor, partición de aplicaciones para escalabilidad de escritura y múltiples esclavos de replicación de lectura para escalabilidad de lectura una base de datos puede ser completamente redundante así como también manejar cantidades crecientes de requerimientos de usuarios. Si es necesario, esta arquitectura también puede ser geográficamente replicada asincrónicamente a un centro de datos de recuperación de falla para propósitos de recuperación de desastre. Load Balancer

Shard 1

Shard 2

IP Management

IP Management

MySQL

MySQL

MySQL

MySQL

DRBD

DRBD

DRBD

DRBD

MySQL

MySQL

Figura 10. Clusters DRBD, partición de aplicaciones, y replicación.

15

MySQL Database Scale-Out and Replication

Sun Microsystems, Inc.

Guías para la Implementación del Escalamiento (Scale-out) La siguientes guías son relevantes al planear para el escalamiento y replicación MySQL: * No piense sincronizadamente No todo acceso a la base de datos necesita suceder al mismo tiempo. * No piense verticalmente Con frecuencia el mejor desempeño puede ser logrado añadiendo servidores por artículos (commodity servers) para servir a segmentos específicos de la arquitectura. * No mezcle transacciones e inteligencia de negocios Ya que es fácil instalar esclavos de replicación, corra aplicaciones deinteligencia de negocios contra esos esclavos, protegiendo al servidor maestro para servir requerimientos de escritura. * Evite mezclar datos calientes y fríos Al instalar esclavos de replicación, asegúrese de poner más tablas estáticas en los esclavos de lectura y mantenga frecuentemente actualizados los espacios de las tablas en el servidor principal MySQL. * No olvide el poder de la memoria Es necesaria suficiente memoria para manejar exitosamente las transacciones entrantes. Configurar memoria adecuada puede ayudar a evitar muchos de los problemas que podría de otra manera forzar a una empresa a adoptar una estrategia complicada de replicación. Una descripción de la instalación básica en la replicación MySQL está incluida en el “Apéndice: Un vistazo a la Instalación de la Replicación MySQL” en la página 18.

Monitoreo MySQL y Servicios Profesionales

MySQL Enterprise Unlimited es otra opción que incluye soporte de producción a través de toda la empresa por una cuota fija, e incluye soporte para un número ilimitado de servidores MySQL.

La organización MySQL ofrece muchas maneras de ayudar a evaluar y crear arquitecturas de replicación. Por el lado del software, la aplicación MySQL Enterprise Monitor ayuda al administrador de la base de datos a ver el estatus de los objetivos de replicación, determinar qué problemas podrían causar que un esclavo de replicación no reciba datos, y supervisar el estatus actual de las actividades de replicación en un servidor corriendo. Acceso al Enterprise Dashboard viene con una subscripción de nivel de soporte de producto MySQL Enterprise Silver, mientras que características más avanzadas tales como el Replication Advisor y Memory Advisor vienen como parte del nivel de soporte MySQL Enterprise Gold Mientras que es completamente gratuito descargar y utilizar la base de datos MySQL pura, el soporte adicional está disponible para ayudar a las empresas a maximizar su experiencia MySQL. Por ejemplo, el producto de MySQL Enterprise incluye los siguientes componentes en varios niveles de suscripción: * El software MySQL Enterprise Server—el más confiable, seguro y la versión más actualizada del software de la base de datos MySQL. * El servicio MySQL Software Update —provee alertas proactivas con respecto a los lanzamientos de nuevos productos, artículos de seguridad y de virus.

16

MySQL Database Scale-Out and Replication

Sun Microsystems, Inc.

* MySQL Knowledge Base —un valioso recurso de auto-ayuda que permite a los usuarios a buscar una biblioteca comprensiva de artículos técnicos para resolver problemas difíciles sobre los tópicos más populares de base de datos. * Soporte MySQL Production —provee soporte de expertos dentro de la organización MySQL quienes pueden dar consejo sobre el desempeño de la base de datos, diseño, y estrategias de implementación, y puede ayudar a resolver problemas en su totalidad. * Servicios MySQL Monitoring and Advisory —funcionan como un asistente virtual del administrador de la base de datos para ayudar a fortalecer las mejores prácticas recomendadas MySQL de todos los servidores MySQL. Nota – Ver http://www.mysql.com/products/enterprise/features.html para más información sobre las características de MySQL Enterprise.

Resumen La base de datos MySQL, la base de datos más popular en cuanto a uso hoy en día, incluye características en las que los negocios apoyan sus operaciones del día-a-día de servicios Web y despliegues empresariales. Aunque grandes cantidades de dinero son cobradas por otras bases de datos en el mercado, la base de datos MySQL ofrece algo que otras bases de datos no: la habilidad para desplegar una base de datos de clase empresaria en virtualmente cualquier hardware, sin costo. Conforme la popularidad de las aplicaciones se incrementa con el tiempo y las demandas de bases de datos back-end crece, es necesario considerar cómo crecer y escalar inteligentemente los despliegues MySQL. Escalar incorrectamente instalaciones MySQL pueden afectar adversamente el desempeño y causar una complejidad injustificada en la infraestructura de la base de datos. Este documento proporcionó información sobre los enfoques al escalamiento (scale out) de la base de datos MySQL, para tratar estos problemas. Una planeación cuidadosa utilizando este documento como guía es un punto de partida. El soporte adicional está disponible a través de la vibrante y responsiva base del usuario MySQL y vía servicios de soporte profesionales, tales como las ofertas de soporte MySQL Production. Con planeación, los despliegues de la base de datos MySQL pueden ser administrados para escalar para cumplir con las demandas de los patrones de crecimiento de bases de datos ahora y en el futuro.

Acerca del Autor Nick Kloski es un Arquitecto de Soluciones Web2.0 en el grupo Web/HPC del equipo de Marketing de Sistemas Técnicos en Sun. En sus 10 años en Sun, Nick ha estado ampliamente expuesto tanto a equipos Sun como a sistemas competitivos, incluyendo trabajo de sistemas de administración, por más de seis años de Servicio de Campo técnico, pruebas internas, y como un miembro del Departamento de Marketing Técnico. En el rol de Arquitecto de Soluciones Web2.0, Nick es responsable de estar atento de las tendencias del mercado y descubrir las formas en que la tecnología de Sun puede ayudar de manera única a resolver problemas de los clientes.

17

MySQL Database Scale-Out and Replication

Sun Microsystems, Inc.

Reconocimientos . Al autor le gustaría reconocer a Jimmy Guerrero del equipo de Marketing MySQL por sus contribuciones a este artículo.

Referencias Base de datos MySQL: http://www.sun.com/software/products/mysql/index.jsp. Documentación MySQL: http://dev.mysql.com/doc/index.html MySQL Enterprise: http://www.mysql.com/products/enterprise/features.html

Ordenar Documentos Sun SM

El programa SunDocs provee más de 250 manuales de Sun Mycrosystems, Inc. Si usted vive en los Estados Unidos, Canadá, Europa, o Japón, usted puede comprar paquetes de documentación o manuales individuales a través de este programa.

Acceder a la Documentación Sun en Línea El sitio web docs.sun.com le permite accesar a la documentación técnica Sun en línea. Usted puede navegar docs.sun.com o buscar el título de un libro específico o tema. El URL es http://docs.sun.com/ Para referencia de artículos Sun Blue Prints Online, visite el sitio Sun BluePrints Online Web en: http://www.sun.com/blueprints/online.html

18

MySQL Database Scale-Out and Replication

Sun Microsystems, Inc.

Apéndice: Un Vistazo a la Instalación de la Replicación MySQL Los siguientes pasos de alto nivel proporcionan una revisión de la instalación básica de la replicación MySQL. Estos pasos no ofrecen comandos específicos necesarios para crear un esclavo de replicación MySQL, pero están incluidos como una herramienta conceptual para proveer un panorama del proceso de replicación.

Nota – Para información más detallada sobre la instalación de la replicación, referirse a la documentación MySQL para la versión específica MySQL que está siendo utilizada. Por ejemplo, El Manual de Referencia MySQL 5.1, capítulo 15 “Replicación” y el Manual de Referencia MySQL 5.0, capítulo 15 “Replicación” ambos describen como instalar una replicación completa de un servidor MySQL sobre las versiones 5.1 y 5.0 respectivamente.

1. Asegúrese que los servidores maestro y esclavo estén configurados con identificaciones (IDs por sus siglas en inglés) únicas. 2. Otorgue privilegios de replicación al esclavo 3. Edite los archivos master/slave my.cnf (registro binario, etc.) 4. Reinicie el servidor maestro 5. Copie los datos del servidor maestro al esclavo (s): - Backup en frío/Restaurar - Mysqldump—opción datos del servidor maestro - Haga un LOCK a las tablas y copie archivos (LOCK tables and file copy) 6. Emita el comando MySQL show master status para registrar el archivo del índice y su posición 7. Emita el comando MySQL stop slave 8. Emita el comando MySQL change master –master_host=, master_user=, master_password,master_log_file=, master_log_pos 10. Emita el comando MySQL start slave

MySQL Database Scale-Out and Replication

On the Web sun.com

Sun Microsystems, Inc. 4150 Network Circle, Santa Clara, CA 95054 USA Phone 1-650-960-1300 or 1-800-555-9SUN (9786) Web sun.com © 2008 Sun Microsystems, Inc. All rights reserved. Sun, Sun Microsystems, the Sun logo, and MySQL are trademarks or registered trademarks of Sun Microsystems, Inc. or its subsidiaries in the United States and other countries. Information subject to change without notice. Printed in USA 11/08