mysql amazon-web-services replication amazon-rds

mysql - ¿Alguien ha descubierto cómo escalar réplicas de lectura de Amazon RDS?



amazon-web-services replication (4)

Creo que HAProxy sería una buena opción para cargar el equilibrio entre múltiples réplicas de lectura. Puedes tener una configuración como esta:

listen mysql-cluster 0.0.0.0:3306 mode tcp balance roundrobin option mysql-check user root server db01 x.x.x.x:3306 check server db02 x.x.x.x:3306 check server db03 x.x.x.x:3306 check

donde xxxx es el punto final de la réplica.

Recientemente, he configurado una réplica de lectura para quitar parte de la carga de lectura de mi instancia de Amazon multi-AZ RDS. La documentación de Amazon establece claramente que depende de su aplicación determinar cómo se distribuye el tráfico de lectura en sus réplicas de lectura.

¿Alguien ha descubierto una manera manejable de escalar las réplicas de lectura? No parece ser una solución muy extensible tener diferentes partes de mi aplicación codificadas para leer réplicas específicas. ¿Hay una manera de configurar esto que sea análoga a poner instancias de EC2 detrás de un equilibrador de carga?


He estado jugando con el uso de Route 53 CNAME ponderado para cargar las réplicas de lectura de RDS (y la fuente). Actualmente tengo 3 conjuntos de registros CNAME para readdb.example.com.

Los primeros puntos a la db de origen en db.example.com. Esto es en caso de que haya un error de replicación. La aplicación puede retroceder a la base de datos original para las lecturas. O si lo desea, puede hacer que la fuente lleve una cierta proporción de la carga de lectura, dependiendo de cómo establezca el peso. La política de enrutamiento se establece en ponderada. Tengo el peso para la fuente establecida en 1, por lo que asume una carga muy pequeña de la carga de lectura. El TTL se establece bajo. He probado valores del 1 al 10. Lo he dejado en 10 por ahora. También debe ingresar un ID de conjunto que sea una cadena única ("Base de datos de origen").

El segundo registro establece puntos a una de las réplicas de lectura (readdb1.blahblah.rds.amazonaws.com). La política de enrutamiento está ponderada, y TTL es 10 como antes. También necesita un ID de conjunto único. Pongo el peso para este entre 5-50, dependiendo. Este, lo asocio con un chequeo de salud, que debes crear con anticipación. Probablemente puedes usar un simple chequeo de salud que apunta a la réplica, pero hice algo un poco diferente.

Pongo un archivo como este en cada uno de mis servidores de aplicaciones (estoy usando PHP Elastic Beanstalk, pero podrías hacer algo similar en otras configuraciones / idiomas que asumo):

<?php if($instanceid = $_GET["id"]): ?> <?php exec("aws rds describe-db-instances --db-instance-identifier " . escapeshellarg($instanceid), $rdsinfo); $rdsinfo = implode('' '',$rdsinfo); $rdsinfo = json_decode($rdsinfo, true); if($rdsinfo["DBInstances"][0]["StatusInfos"][0]["Normal"] && $rdsinfo["DBInstances"][0]["DBInstanceStatus"] === "available"){ echo "GOOD!"; } else { echo "BAD!"; }; /* Then there''s some other stuff in here that is a little unrelated to the question */ ?> <?php endif ?>

Este archivo utiliza la interfaz de línea de comandos de AWS que se instala en las aplicaciones Elastic Beanstalk y solo requiere que las variables de entorno para AWS_ACCESS_KEY_ID, AWS_DEFAULT_REGION y AWS_SECRET_KEY se especifiquen con anticipación. Entonces, realiza una comprobación de estado de Route 53 que apunta a http://www.example.com/rdshealthcheck/rdsshealthcheck.php?id=readdb1 . Estableciste la cadena de búsqueda en "¡BUENO!" Creo que una cadena de búsqueda cuesta $ 1 / mes / chequeo de salud, lo que parece razonable.

Si tiene una segunda réplica de lectura, puede crear otro chequeo de salud que apunte a http://www.example.com/rdshealthcheck/rdsshealthcheck.php?id=readdb2 o como se llame.

En realidad solo uso una réplica de lectura en este momento, pero es significativamente más grande que mi base de datos de origen. Fue más económico para mí, porque mi DB de origen es multi-az. Mantengo el tercer conjunto de registros y el segundo chequeo de salud en caso de que la primera réplica me esté dando problemas. De esa manera, no tengo que esperar a que se elimine el primero antes de volver a iniciarlo. En cambio, elimino inmediatamente el primero y lanzo el segundo con el nombre especificado en el tercer juego de registros (y la segunda verificación de estado).


Me gustaría sugerir un enfoque más conveniente.
Que es, DNS Round-robin con Amazon Route 53 .

Como puedes ver en este article ,
Amazon Route 53 puede hacer Round-robin con múltiples CNAME.

Entonces todo lo que necesitas hacer es

  1. "Creando Conjuntos de Registros" en la Ruta 53.
  2. Actualice su archivo de configuración de su aplicación.

En mi caso, este enfoque funciona bien.


Un ingeniero de AWS proporcionó información sobre la pregunta here .

Aquí hay un fragmento de su respuesta:

en general, puede equilibrar la carga del tráfico en los siguientes 3 lugares lógicos:

  • Capa de aplicación: cree múltiples agrupaciones de conexiones y envíe todas las lecturas a las réplicas de lectura.
  • Marco web / middleware: algunos marcos web tienen soporte incorporado para múltiples bases de datos [1].
  • Proxy externo: puede usar un proxy externo como MySQLproxy [2].

[1] - https://docs.djangoproject.com/en/dev/topics/db/multi-db/

[2] - https://launchpad.net/mysql-proxy