Comparación de RDS y EC2 para administrar MySQL o MariaDB en AWS

RDS es una base de datos como servicio (DBaaS) que configura y mantiene automáticamente sus bases de datos en la nube de AWS. El usuario tiene un poder limitado sobre configuraciones específicas en comparación con la ejecución de MySQL directamente en Elastic Compute Cloud (EC2). Pero RDS es un servicio conveniente, siempre que pueda vivir con las instancias y configuraciones que ofrece.

Amazon RDS actualmente es compatible con varias versiones de MySQL y MariaDB, así como con el motor de base de datos Amazon Aurora compatible con MySQL. Admite la replicación, pero como es de esperar de una consola web predefinida, existen algunas limitaciones.

Hay algunas ventajas y desventajas al usar RDS. Estos pueden no solo afectar la forma en que administra y aprovisiona sus instancias de base de datos, sino también aspectos clave como el rendimiento, la seguridad y la alta disponibilidad.

En este blog, veremos las diferencias entre usar RDS y ejecutar MySQL en EC2, centrándonos en la replicación. Como veremos, decidir entre alojar MySQL en una instancia EC2 o usar Amazon RDS no es tarea fácil.

Compensaciones de la plataforma RDS

El tamaño más grande de la base de datos que AWS puede alojar depende de su entorno de origen, la asignación de datos en su base de datos de origen y cuán ocupado está su sistema.

AWS se divide en regiones. Cada cuenta de AWS tiene límites, por región, en la cantidad de recursos de AWS que se pueden crear. Una vez que se alcanza el límite de un recurso, fallarán las llamadas adicionales para crear ese recurso.

Para las instancias de base de datos MySQL de Amazon RDS, el límite máximo de almacenamiento aprovisionado restringe el tamaño de una tabla a un tamaño máximo de 6 TB cuando se utilizan espacios de tablas de archivo por tabla de InnoDB.

La función de archivo por tabla de InnoDB es algo que debe considerar incluso si no está buscando migrar una gran base de datos a la nube. Es posible que observe que algunas instancias de base de datos existentes tienen un límite inferior. Por ejemplo, las instancias de base de datos MySQL creadas antes de abril de 2014 tienen un límite de tamaño de archivo y tabla de 2 TB. Este límite de tamaño de archivo de 2 TB también se aplica a instancias de base de datos o réplicas de lectura creadas a partir de instantáneas de base de datos tomadas antes de abril de 2014.

Una de las diferencias clave que afecta la forma en que configura y mantiene la replicación de la base de datos es la falta de un usuario SUPER. Para abordar esta limitación, Amazon introdujo procedimientos almacenados que se encargan de varias tareas de DBA. A continuación se encuentran los procedimientos clave para administrar la replicación MySQL RDS.

Omitir error de replicación:

CALL mysql.rds_skip_repl_error;

Detener la replicación:

CALL mysql.rds_stop_replication;

Iniciar replicación

CALL mysql.rds_start_replication;

Configura una instancia de RDS como réplica de lectura de una instancia de MySQL que se ejecuta fuera de AWS.

CALL mysql.rds_set_external_master;

Reconfigura una instancia de MySQL para que ya no sea una réplica de lectura de una instancia de MySQL que se ejecuta fuera de AWS.

CALL mysql.rds_reset_external_master;

Importa un certificado. Esto es necesario para habilitar la comunicación SSL y la replicación cifrada.

CALL mysql.rds_import_binlog_ssl_material;

Elimina un certificado.

CALL mysql.rds_remove_binlog_ssl_material;

Cambia la posición del registro maestro de replicación al inicio del siguiente registro binario en el maestro.

CALL mysql.rds_next_master_log;

Si bien los procedimientos almacenados se encargan de una serie de tareas, es una pequeña curva de aprendizaje. La falta de privilegio SUPER también puede crear problemas al usar la supervisión de replicación externa.

Amazon RDS actualmente no admite lo siguiente:

• ID de transacciones globales
• Espacio de mesa transportable
• Complemento de autenticación
• Complemento de seguridad de contraseña
• Filtros de replicación
• Replicación semisincrónica

Por último, pero no menos importante, acceda al shell. Amazon RDS no permite el acceso directo del host a una instancia de base de datos a través de Telnet, Secure Shell (SSH) o Windows Remote Desktop Connection (RDP). Todavía puede usar el cliente en un host de aplicaciones para conectarse a la base de datos a través de herramientas estándar como el cliente mysql.

Existen otras limitaciones, como se describe en la documentación de RDS.

Alta disponibilidad con MySQL en EC2

Para automatizar las tareas de implementación y administración/mantenimiento (manteniendo el control), es posible usar ClusterControl. Al igual que con RDS, tiene la comodidad de implementar una configuración de base de datos en unos minutos a través de una GUI. La adición de nodos, la programación de copias de seguridad, la realización de conmutación por error, etc., también se pueden realizar cómodamente a través de la GUI. Hay opciones para operar MySQL directamente en EC2 y, por lo tanto, mantener el control de las opciones de alta disponibilidad. Al seguir esta ruta, es importante comprender cómo aprovechar las diferentes funciones de AWS que están a su disposición. Asegúrese de consultar nuestro documento técnico "DIY Cloud Database".

Despliegue

ClusterControl puede automatizar la implementación de diferentes configuraciones de bases de datos de alta disponibilidad, desde la replicación maestro-esclavo hasta clústeres multimaestros. Se admiten todas las versiones principales de MySQL:Oracle MySQL, MariaDB y Percona Server. Se requiere alguna configuración inicial de VPC/grupo de seguridad, y estos están bien descritos en el documento técnico DIY Cloud Database. Tenga en cuenta que se aplican conceptos similares, ya sea AWS, Google Cloud o Azure

Galera Cluster es una buena alternativa a tener en cuenta al implementar un servicio MySQL de alta disponibilidad. Se ha establecido como un reemplazo creíble para las arquitecturas maestro-esclavo tradicionales de MySQL, aunque no es un reemplazo directo. La mayoría de las aplicaciones aún se pueden adaptar para ejecutarse en él. Es posible definir diferentes segmentos para bases de datos que se extienden por varias regiones de AWS.

Es posible configurar la "replicación híbrida" combinando la replicación síncrona dentro de un Galera Cluster y la replicación asíncrona entre el clúster y uno o más esclavos. Opciones como retrasar el esclavo brindan un nivel adicional de protección a los datos.

Capa de proxy

Para lograr una alta disponibilidad, no basta con implementar una configuración de alta disponibilidad. Las aplicaciones tienen que saber de alguna manera qué nodos están funcionando y cuáles no. Cambios en la topología, p. mover un maestro a otro host, también debe propagarse de alguna manera para evitar errores en la capa de aplicación. ClusterControl admite implementaciones de proxies como HAProxy, MaxScale y ProxySQL. Para HAProxy y ProxySQL, existen opciones adicionales para implementar instancias redundantes con Keepalived y VirtualIP.

Réplica entre regiones

Amazon RDS proporciona servicios de réplica de lectura. Las réplicas entre regiones le brindan la capacidad de escalar las lecturas, ya que AWS tiene sus servicios en varios centros de datos en todo el mundo. Todas las réplicas de lectura son accesibles y se pueden usar para leer en un número máximo de cinco regiones. Estos nodos son independientes y se pueden usar en su ruta de actualización o se pueden promocionar a bases de datos independientes.

Además de eso, Amazon ofrece implementaciones Multi-AZ basadas en DRBD, replicación de disco síncrona. ¿En qué se diferencia de las réplicas de lectura? La principal diferencia es que solo está activo el motor de la base de datos en la instancia principal, lo que genera otras variaciones arquitectónicas.

A diferencia de las réplicas de lectura, las actualizaciones de la versión del motor de la base de datos se realizan en la principal. Otra diferencia es que AWS RDS realizará la conmutación por error automáticamente con DRBD, mientras que las réplicas de lectura (usando la replicación asíncrona) requerirán operaciones manuales por su parte.

La conmutación por error Multi-AZ en RDS usa un cambio de DNS para apuntar a la instancia en espera; según Amazon, esto debería ocurrir dentro de los 60 a 120 segundos durante la conmutación por error. Debido a que el modo de espera usa los mismos datos de almacenamiento que el principal, probablemente habrá una recuperación de transacciones/registro. Las bases de datos más grandes pueden dedicar una cantidad significativa de tiempo a la recuperación de InnoDB, así que considere eso en su plan de recuperación ante desastres y cálculo de RTO.

Por supuesto, esto va con un costo adicional. Echemos un vistazo a un ejemplo básico. El costo del host db.t2.medium con 2vCPU, 4 GB de RAM es de 185,98 USD por mes, el precio se duplicará cuando habilite la réplica multizona (MZ) a 370,98 UDB. El precio variará según la región, pero se duplicará en MZ.

Para lograr lo mismo con EC2, puede implementar sus máquinas virtuales en diferentes regiones. Cada región de AWS es completamente independiente. La configuración de la región de AWS se puede cambiar en la consola, configurando la variable de entorno EC2_REGION, o se puede anular utilizando el parámetro --region con la interfaz de línea de comandos de AWS. Cuando su conjunto de servidores esté listo, puede usar ClusterControl para implementar y monitorear su replicación. También puede configurar manualmente la replicación a través de la consola usando comandos estándar.

Replicación entre tecnologías

Es posible configurar la replicación entre una instancia de base de datos MySQL o MariaDB de Amazon RDS y una instancia de MySQL o MariaDB externa a Amazon RDS. Esto se hace usando el método de replicación estándar en mysql, a través de registros binarios. Para habilitar los registros binarios, debe modificar la configuración de my.cnf. Sin acceso al shell, esta tarea se volvió imposible en RDS. Está hecho de una manera no tan obvia. Tienes dos opciones. Una es habilitar las copias de seguridad:establezca copias de seguridad automáticas en su instancia de base de datos de Amazon RDS con una retención superior a 0. O habilite la replicación en un servidor esclavo preconstruido. Ambas tareas habilitarán registros binarios que luego podrá usar para su replicación.

Mantenga los binlogs en su instancia maestra hasta que haya verificado que se han aplicado en la réplica. Este mantenimiento garantiza que pueda restaurar su instancia maestra en caso de falla.

Otro obstáculo pueden ser los permisos. Los permisos necesarios para iniciar la replicación en una instancia de base de datos de Amazon RDS están restringidos y no están disponibles para su usuario maestro de Amazon RDS. Debido a esto, debe utilizar los comandos mysql.rds_set_external_master y mysql.rds_start_replication de Amazon RDS para configurar la replicación entre su base de datos activa y su base de datos de Amazon RDS.

Supervise los eventos de conmutación por error para la instancia de Amazon RDS que es su réplica. Si se produce una conmutación por error, es posible que la instancia de base de datos que es su réplica se vuelva a crear en un nuevo host con una dirección de red diferente. Para obtener información sobre cómo monitorear eventos de conmutación por error, consulte Uso de la notificación de eventos de Amazon RDS.

En el siguiente ejemplo, veremos cómo habilitar la replicación desde RDS a una base de datos externa ubicada en una instancia EC2.
Debe tener habilitados los registros binarios, aquí usamos un esclavo RDS.

Especifique la cantidad de horas para conservar los registros binarios.

mysql -h RDS_MASTER -u<username> -u<password>
call mysql.rds_set_configuration('binlog retention hours', 7);

En RDS MASTER, cree un usuario de replicación con los siguientes comandos:

CREATE USER 'repl'@'ec2DBslave' IDENTIFIED BY 's3cr3tp4SSw0rd';
GRANT REPLICATION SLAVE ON *.* TO 'repl'@'ec2DBslave';

En RDS SLAVE, ejecute los comandos:

mysql -u<username> -u<password> -h RDS_SLAVE
call mysql.rds_stop_replication;
SHOW SLAVE STATUS;  Exec_Master_Log_Pos, Relay_Master_Log_File.

En RDS SLAVE, ejecute mysqldump con el siguiente formato:

mysqldump -u<username> -u<password> -h RDS_SLAVE --routines --triggers --single-transaction --databases DB1 DB2 DB3 > mysqldump.sql

Importe el volcado de base de datos a una base de datos externa:

mysql -u<username> -u<password> -h ec2DBslave
tee import_database.log;
source mysqldump.sql;

CHANGE MASTER TO 
 MASTER_HOST='RDS_MASTER', 
 MASTER_USER='repl',
 MASTER_PASSWORD='s3cr3tp4SSw0rd',
 MASTER_LOG_FILE='<Relay_Master_Log_File>',
 MASTER_LOG_POS=<Exec_Master_Log_Pos>;

Cree un filtro de replicación para ignorar las tablas creadas por AWS solo en RDS

CHANGE REPLICATION FILTER REPLICATE_WILD_IGNORE_TABLE = ('mysql.rds\_%');

Iniciar replicación

START SLAVE;

Verificar estado de replicación

SHOW SLAVE STATUS;

Eso es todo por ahora. Administrar MySQL en AWS es un gran tema. Háganos saber sus pensamientos en la sección de comentarios a continuación.