Soy un gran admirador de AWS en general ... pero RDS, no tanto.
@RolandoMySQLDBA ha señalado que hay algunos puntos bastante buenos en su contra.
La única ventaja que veo en RDS en comparación con MySQL en EC2 es la capacidad de hacer instantáneas de apuntar y hacer clic, clones y recuperación en un punto en el tiempo, pero no son suficientes para compensar la pérdida de control y flexibilidad, y ciertamente no justifica que el precio sea más alto. RDS es sexy en algunos aspectos, pero no puedes confiar en lo que finalmente no puedes arreglar, porque no puedes acceder a todas las partes móviles.
No me gusta no tener el SUPERprivilegio. No me gusta no poder seguir el registro de errores. No me gusta no poder ejecutar "top" o "iostat" en mi servidor de base de datos para ver cómo los núcleos y las unidades disfrutan de la carga. No me gusta no tener acceso al motor de almacenamiento federado. No me gusta la idea de pagar por una máquina maestra de respaldo en caliente (multi-AZ) que ni siquiera puedo aprovechar como réplica de lectura. Claro, hay explicaciones perfectamente razonables de por qué todas estas restricciones tienen que estar establecidas para que MySQL pueda empaquetarse y venderse con éxito como RDBMS-in-a-box. Lo único es que RDBMS-in-a-box "resuelve" toda una serie de problemas que no tengo ... y se interpone en mi camino, causando nuevos problemas.
Pero el factor decisivo para mí con RDS es la falta total de acceso a los registros binarios y la replicación. Los binlogs, especialmente los basados en filas, son una fantástica herramienta de recuperación para desastres menores, pero no son de ayuda si no puede acceder a ellos. ¿Desea configurar un servidor local en su oficina como una réplica de lectura de su base de datos de producción en RDS? Algo de lo que tomar copias de seguridad locales, informes, tener a mano para la recuperación ante desastres, ¿debería suceder algo impensable a sus datos que viven en RDS? Esa es una idea que es a la vez obvia y brillante.
Vaya, lo siento, el acceso directo a la replicación no está disponible. Claro, puede pagar las réplicas de lectura ... pero solo como otras instancias de RDS. No es una propuesta de valor en mi libro.
Actualización: un cambio significativo en RDS para MySQL 5.6
Yo prefiero tener mi propio servidor (incluso en EC2) en lugar de correr RDS para una serie de razones, incluyendo la falta de apoyo a las funciones definidas por el usuario , la imposibilidad de utilizar el motor de almacenamiento , y la incapacidad de tener el uno conexión adicional disponible para acceso de emergencia ... sin embargo ...
Amazon ha realizado un cambio significativo en MySQL 5.6 para RDS que elimina una de mis principales objeciones, tal vez mi mayor objeción: ahora se puede acceder a los registros binarios y puede ejecutar una instancia que no sea RDS como esclava o conectar otras utilidades a servidor que lee la secuencia binlog.
http://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/MySQL.Procedural.Exporting.NonRDSRepl.html
Oficialmente, la documentación indica que están exponiendo esto para que pueda configurar un esclavo con el fin de realizar una migración en vivo: sincronice el futuro servidor maestro externo de la instancia RDS existente utilizando mysqldump, luego conéctelo a RDS como esclavo para obtener una transmisión en vivo de actualizaciones a través de la secuencia de replicación hasta que su aplicación se migre al nuevo maestro, pero de manera no oficial, puede hacerlo de manera continua siempre que no espere que lo apoyen ... lo cual, A mí me parece razonable.
Esto se confirmó en un seminario web reciente , en una conversación que comienza alrededor de las 56:45:
"Puede mantenerlo en un estado replicado indefinidamente ...
"... siempre y cuando asumas la responsabilidad de mantener la replicación ..."
"No estamos evitando que realice una replicación continua si eso es lo que desea".
Esta nueva capacidad fue suficiente para que soltara mi objeción general al uso de RDS en nuestras instancias de MySQL que respaldan el sitio web, donde no usamos FEDERATEDo algunas de las otras cosas tanto o en absoluto.
Así que todavía no estoy a favor, pero ya no estoy en contra, ya que tener una transmisión en vivo de los registros binarios me devuelve finalmente el control de los datos en tiempo real y la responsabilidad de garantizar que no se realicen transacciones. Perdido en una interrupción catastrófica está de vuelta conmigo, porque yo, como DBA, recupero el control, que es exactamente como lo quiero. Tener un proveedor externo para señalar con el dedo, o presentar una demanda contra, o lo que sea, no recupera los datos perdidos si desaparece por un agujero negro dentro de una caja negra.
A la administración parece gustarle la "idea" de RDS y no se opone a la diferencia de costos, por lo que ahora estamos lanzando todos los sitios web nuevos con RDS detrás de ellos.
La recuperación de apuntar y hacer clic en un punto en el tiempo, lo admito, es una buena característica en RDS ... no altera ni interrumpe su máquina existente; en cambio, enciende una instancia completamente nueva, utilizando la copia de seguridad que fue más cercano en el tiempo al punto seleccionado en el tiempo, y luego aplica los binlogs necesarios para llevar esa nueva máquina al punto en el tiempo que ha especificado.
En relación con esto, pero en la otra dirección, también es posible, ahora, usar una estrategia similar para migrar una base de datos MySQL en vivo a RDS ... puede conectar un maestro RDS (presumiblemente, por lo general, esto sería un nuevo despliegue instancia) como esclavo de un sistema existente para que la instancia de RDS tenga la versión en vivo de los datos al momento de migrar a ella. A diferencia del acceso a los binlogs RDS para la replicación externa, que solo funciona en 5.6, la replicación interna es compatible con RDS a partir de 5.5.33 y 5.6.13.