¿Formas de escalar automáticamente los servidores MySQL?

Dirijo un sitio que tiene un alto tráfico y, debido a eso, las soluciones de escalado automático son muy rentables para este caso. Actualmente, el servidor web puede escalar automáticamente horizontalmente, pero el cuello de botella está en el servidor MySQL.

• He intentado con Amazon RDS Multi-AZ, pero la base de datos de 12 GB tarda unos 15 minutos en actualizarse con algunos minutos de inactividad. Me ayudó mucho cuando ya sabía que iba a ocurrir un aumento de tráfico en algún momento específico.
• También he considerado Xeround. Esta es probablemente la mejor solución, aunque es bastante costosa para bases de datos de este tamaño. De todos modos, no es una opción porque legalmente necesito que la base de datos esté en la Unión Europea.
• He leído sobre Scalr pero no estoy seguro de si eso podría ser útil y cómo.
• He visto que muchos proveedores de alojamiento en la nube ofrecen soluciones de escala vertical que creo que tiene 0 tiempo de inactividad (no estoy seguro de si eso es realmente posible, por lo que sé, usan el hipervisor Xen). Esa podría ser una solución, pero me pregunto si no tiene tiempo de inactividad y cómo la configuración de MySQL (y muchas otras cosas en el sistema operativo) pueden actualizarse también sin tiempo de inactividad.
• He intentado con servidores esclavos MySQL pero no fue de ninguna ayuda.
• Estoy usando memcache que ayuda mucho pero no es suficiente. Necesito actualizar debido a escrituras, no solo por lecturas.

¿Alguna sugerencia? Gracias de antemano

En realidad, una solución más simple sería intentar agregar Memcached a su pila para ahorrar en la carga de la base de datos. Esto puede ahorrar drásticamente la carga, y es mucho más simple que tratar de resolver el problema de los servidores de pie rápidamente (baja dificultad), y luego calcular una sincronización rápida de MySQL (dificultad mucho mayor).

http://toblender.com/?s=memcached

Para resolver el problema de demasiadas escrituras, la solución más común es agregar memoria al servidor (se puede mantener un conjunto de trabajo más grande en la RAM), poner su base de datos en discos más rápidos (los SSD son una buena solución, pero costosa) o fragmentar (que es costoso en servidores adicionales y complejidad).

Otra forma de reducir la carga de escritura de DB sería incorporar un almacén de datos en memoria (como Redis) para manejar datos que cambian con frecuencia y, si es necesario, escribir periódicamente los cambios en su DB principal.

Debe considerar usar una topología en estrella

Esto es lo que estoy proponiendo

• One Write Master (también conocido como WM)
• Un maestro de distribución (también conocido como DM)
• Cinco (5) servidores esclavos de lectura (también conocidos como RSS)

Prepare la topología como esta

Paso 01: Configura 5 RSS con estas opciones comunes

[mysqld]
skip-innodb
key_buffer_size=1G

Esto hará que todas las tablas se creen cargadas como MyISAM Storage Engine

Paso 02: Configurar DM y todos los servidores RS

• mysqldump el esquema de todas las tablas desde WM a un archivo de esquema
• cargar el archivo de Schemadump en DM y los 5 RSS
• ejecutar ALTER TABLE tblname ROW_FORMAT=Fixed;en todas las tablas en RSS
• ejecutar ALTER TABLE tblname ENGINE=BLACKHOLE;en todas las tablas en DM
• solo datos de mysqldump (usando --no-create-info) a un datadump
• cargar datadump en los 5 RSS

Paso 03: Configurar la replicación de DM a los 5 RSS

Paso 04: Configurar la replicación de WM a DM

FIN DE LA CONFIGURACIÓN

Así es como funciona su mecanismo de lectura / escritura

• Todas sus escrituras (INSERTOS, ACTUALIZACIONES, DELETES) ocurren en el WM
• SQL se registra en los registros binarios de DM (no hay datos reales en DM)
• Cada RSS es un esclavo de lectura al DM
• Todas sus lecturas ocurren en el RSS

Ahora aquí está la trampa ...

• Utiliza RSS 1-4 para lecturas inicialmente
• Use el 5to RSS para activar otros RSS
  • Corres service mysql stopen el 5to RSS
  • Spin Up otro RSS
  • Copie / var / lib / mysql y /etc/my.cnf del 5to RSS al RSS recién creado
  • Corres service mysql stopen el 5to RSS
  • Corres service mysql stopen el nuevo RSS

Puede usar RSS # 5 para activar nuevos servidores una y otra vez

En una nota al margen, no use XEROUND para WM o DM porque no son compatibles con el motor de almacenamiento InnoDB o BLACKHOLE.

Espero que estas ideas ayuden.

Si usa Innodb, debe considerar Mysql multi-masters administrado por Galera . Hace que la configuración de mysql multi-master sea más fácil, y debería facilitarle la escala automática "semi".

Si esta es una aplicación que usted o su empresa está escribiendo, puede considerar pasar a un diseño fragmentado (particionado) para la aplicación. Pero el fragmentación puede ser complicado. Aquí hay un enlace para comenzar.

Supongo que ha "ajustado" los archivos de configuración de mysql, como en la memoria asignada apropiada, etc.

¿Está en un rack que controlas o está en la nube? 12GB es una base de datos muy pequeña en relación con el tamaño de los discos disponibles. Póngalo en una matriz RAID1 o RAID10 de SSD SLC pequeños y su latencia de escritura desaparecerá.

El SSD SLC de la serie Intel 311 de 20 GB ($ 120 cada uno) haría el trabajo de manera brillante.

Si la base de datos fuera más grande, podría lograr resultados igualmente espectaculares moviendo su base de datos a un objetivo iSCSI en un servidor SAN ZFS (construido en hardware de servidor básico usando Nexenta, OpenIndiana, FreeNAS o lo que sea) y configurando un espejo de SSD similares para su caché de escritura ZIL. En todas las circunstancias, excepto en las más extraordinarias, Gigabit Ethernet es más que adecuado para mover el tráfico iSCSI de la base de datos.