Confronto tra RDS e EC2 per la gestione di MySQL o MariaDB su AWS

RDS è un Database as a Service (DBaaS) che configura e gestisce automaticamente i tuoi database nel cloud AWS. L'utente ha un potere limitato su configurazioni specifiche rispetto all'esecuzione di MySQL direttamente su Elastic Compute Cloud (EC2). Ma RDS è un servizio conveniente, purché tu possa convivere con le istanze e le configurazioni che offre.

Amazon RDS attualmente supporta varie versioni di MySQL e MariaDB, nonché il motore di database Amazon Aurora compatibile con MySQL. Supporta la replica, ma come ci si può aspettare da una console Web predefinita, ci sono alcune limitazioni.

Ci sono alcuni compromessi quando si utilizza RDS. Questi potrebbero non solo influenzare il modo in cui gestisci e fornisci le istanze del database, ma anche aspetti chiave come prestazioni, sicurezza e disponibilità elevata.

In questo blog, daremo un'occhiata alle differenze tra l'utilizzo di RDS e l'esecuzione di MySQL su EC2, con particolare attenzione alla replica. Come vedremo, decidere tra ospitare MySQL su un'istanza EC2 o utilizzare Amazon RDS non è un compito facile.

Compromessi della piattaforma RDS

La dimensione maggiore del database che AWS può ospitare dipende dall'ambiente di origine, dall'allocazione dei dati nel database di origine e dall'occupazione del sistema.

AWS è suddiviso in regioni. Ogni account AWS ha limiti, per regione, sul numero di risorse AWS che possono essere create. Una volta raggiunto un limite per una risorsa, le chiamate aggiuntive per creare quella risorsa non riusciranno.

Per le istanze database MySQL di Amazon RDS, il limite massimo di storage con provisioning vincola la dimensione di una tabella a una dimensione massima di 6 TB quando si utilizzano tablespace file per tabella InnoDB.

La funzionalità file per tabella di InnoDB è qualcosa che dovresti considerare anche se non stai cercando di migrare un grande database nel cloud. Potresti notare che alcune istanze database esistenti hanno un limite inferiore. Ad esempio, le istanze database MySQL create prima di aprile 2014 hanno un limite per le dimensioni di file e tabelle di 2 TB. Questo limite per le dimensioni del file di 2 TB si applica anche alle istanze database o alle repliche di lettura create da snapshot database acquisiti prima di aprile 2014.

Una delle differenze chiave che influisce sul modo in cui si imposta e si gestisce la replica del database è la mancanza dell'utente SUPER. Per ovviare a questa limitazione, Amazon ha introdotto stored procedure che si occupano di varie attività DBA. Di seguito sono riportate le procedure chiave per gestire la replica RDS MySQL.

Salta l'errore di replica:

CALL mysql.rds_skip_repl_error;

Interrompi la replica:

CALL mysql.rds_stop_replication;

Avvia la replica

CALL mysql.rds_start_replication;

Configura un'istanza RDS come replica di lettura di un'istanza MySQL in esecuzione al di fuori di AWS.

CALL mysql.rds_set_external_master;

Riconfigura un'istanza MySQL in modo che non sia più una replica di lettura di un'istanza MySQL in esecuzione al di fuori di AWS.

CALL mysql.rds_reset_external_master;

Importa un certificato. Ciò è necessario per abilitare la comunicazione SSL e la replica crittografata.

CALL mysql.rds_import_binlog_ssl_material;

Rimuove un certificato.

CALL mysql.rds_remove_binlog_ssl_material;

Modifica la posizione del log del master di replica all'inizio del log binario successivo sul master.

CALL mysql.rds_next_master_log;

Sebbene le stored procedure si occupino di una serie di attività, è un po' una curva di apprendimento. La mancanza del privilegio SUPER può anche creare problemi nell'utilizzo del monitoraggio della replica esterna.

Amazon RDS attualmente non supporta quanto segue:

• ID transazione globali
• Spazio tavolo trasportabile
• Plugin di autenticazione
• Plugin per la sicurezza della password
• Filtri di replica
• Replica semisincrona

Ultimo ma non meno importante:l'accesso alla shell. Amazon RDS non consente l'accesso diretto dell'host a un'istanza database tramite Telnet, Secure Shell (SSH) o Windows Remote Desktop Connection (RDP). Puoi comunque utilizzare il client su un host dell'applicazione per connetterti al DB tramite strumenti standard come il client mysql.

Esistono altre limitazioni, come descritto nella documentazione RDS.

Elevata disponibilità con MySQL su EC2

Per automatizzare la distribuzione e le attività di gestione/manutenzione (mantenendo il controllo), è possibile utilizzare ClusterControl. Proprio come con RDS, hai la comodità di implementare una configurazione di database in pochi minuti tramite una GUI. L'aggiunta di nodi, la pianificazione dei backup, l'esecuzione di failover e così via possono essere comodamente eseguiti tramite la GUI. Sono disponibili opzioni per utilizzare MySQL direttamente su EC2 e quindi mantenere il controllo delle proprie opzioni di alta disponibilità. Quando si percorre questa strada, è importante capire come sfruttare le diverse funzionalità di AWS a tua disposizione. Assicurati di consultare il nostro white paper "Database cloud fai-da-te".

Distribuzione

ClusterControl può automatizzare la distribuzione di diverse configurazioni di database ad alta disponibilità, dalla replica master-slave ai cluster multi-master. Sono supportate tutte le principali versioni di MySQL:Oracle MySQL, MariaDB e Percona Server. Sono necessarie alcune impostazioni iniziali di VPC/gruppo di sicurezza e queste sono ben descritte nel white paper del database cloud fai-da-te. Tieni presente che si applicano concetti simili, sia che si tratti di AWS o di Google Cloud o di Azure

Galera Cluster è una buona alternativa da considerare quando si distribuisce un servizio MySQL ad alta disponibilità. Si è affermato come un sostituto credibile delle tradizionali architetture MySQL master-slave, sebbene non sia un sostituto drop-in. La maggior parte delle applicazioni può ancora essere adattata per essere eseguita su di essa. È possibile definire segmenti diversi per database che si estendono su più regioni AWS.

È possibile impostare la "replica ibrida" combinando la replica sincrona all'interno di un cluster Galera e la replica asincrona tra il cluster e uno o più slave. Opzioni come il ritardo dello slave offrono un ulteriore livello di protezione ai dati.

Livello proxy

Per ottenere un'elevata disponibilità, la distribuzione di una configurazione ad alta disponibilità non è sufficiente. Le applicazioni devono in qualche modo sapere quali nodi funzionano e quali no. Modifiche alla topologia, ad es. anche lo spostamento di un master su un altro host deve essere propagato in qualche modo in modo da evitare errori nel livello dell'applicazione. ClusterControl supporta le distribuzioni di proxy come HAProxy, MaxScale e ProxySQL. Per HAProxy e ProxySQL, sono disponibili ulteriori opzioni per distribuire istanze ridondanti con Keepalived e VirtualIP.

Replica in più regioni

Amazon RDS fornisce servizi di replica di lettura. Le repliche tra regioni ti danno la possibilità di scalare le letture, poiché AWS offre i suoi servizi in numerosi data center in tutto il mondo. Tutte le repliche di lettura sono accessibili e possono essere utilizzate per la lettura in un numero massimo di cinque regioni. Questi nodi sono indipendenti e possono essere utilizzati nel percorso di aggiornamento o possono essere promossi a database autonomi.

Inoltre, Amazon offre implementazioni Multi-AZ basate su DRBD, replica sincrona del disco. In che cosa differisce dalle repliche di lettura? La differenza principale è che solo il motore di database sull'istanza primaria è attivo, il che porta ad altre variazioni dell'architettura.

A differenza delle repliche di lettura, gli aggiornamenti della versione del motore di database avvengono sul server primario. Un'altra differenza è che AWS RDS eseguirà automaticamente il failover con DRBD, mentre le repliche di lettura (usando la replica asincrona) richiederanno operazioni manuali da parte tua.

Il failover multi-AZ su RDS utilizza una modifica DNS per puntare all'istanza di standby, secondo Amazon ciò dovrebbe avvenire entro 60-120 secondi durante il failover. Poiché lo standby utilizza gli stessi dati di archiviazione del primario, probabilmente si verificherà il ripristino delle transazioni/registri. Database più grandi potrebbero dedicare una notevole quantità di tempo al ripristino di InnoDB, quindi tienilo presente nel tuo piano DR e nel calcolo dell'RTO.

Naturalmente, questo va con un costo aggiuntivo. Diamo un'occhiata ad alcuni esempi di base. Il costo dell'host db.t2.medium con 2vCPU, 4 GB di ram è di 185,98 USD al mese, il prezzo raddoppierà quando si abilita la replica Multizone (MZ) a 370,98 UDB. Il prezzo varierà in base alla regione ma raddoppierà in MZ.

Per ottenere lo stesso risultato con EC2, puoi distribuire le tue macchine virtuali in diverse regioni. Ogni regione AWS è completamente indipendente. L'impostazione della regione AWS può essere modificata nella console, impostando la variabile di ambiente EC2_REGION, oppure può essere sovrascritta utilizzando il parametro --region con AWS Command Line Interface. Quando il set di server è pronto, è possibile utilizzare ClusterControl per distribuire e monitorare la replica. Puoi anche impostare manualmente la replica tramite la console utilizzando i comandi standard.

Replica multitecnologica

È possibile configurare la replica tra un'istanza database MySQL o MariaDB Amazon RDS e un'istanza MySQL o MariaDB esterna ad Amazon RDS. Questo viene fatto utilizzando il metodo di replica standard in mysql, tramite log binari. Per abilitare i log binari, è necessario modificare la configurazione my.cnf. Senza l'accesso alla shell, questo compito è diventato impossibile in RDS. È fatto in un modo non così ovvio. Hai due opzioni. Uno è abilitare i backup:impostare backup automatici sull'istanza database Amazon RDS con una conservazione superiore a 0. Oppure abilitare la replica su un server slave predefinito. Entrambe le attività abiliteranno i log binari che potrai utilizzare in seguito per la tua replica.

Mantieni i binlog nell'istanza master finché non avrai verificato che siano stati applicati alla replica. Questa manutenzione assicura che tu possa ripristinare la tua istanza master in caso di errore.

Un altro ostacolo possono essere le autorizzazioni. Le autorizzazioni necessarie per avviare la replica su un'istanza database Amazon RDS sono limitate e non disponibili per l'utente master Amazon RDS. Per questo motivo, devi utilizzare i comandi mysql.rds_set_external_master e mysql.rds_start_replication di Amazon RDS per configurare la replica tra il tuo database live e il tuo database Amazon RDS.

Monitora gli eventi di failover per l'istanza Amazon RDS che è la tua replica. Se si verifica un failover, l'istanza database che è la tua replica potrebbe essere ricreata su un nuovo host con un indirizzo di rete diverso. Per informazioni su come monitorare gli eventi di failover, consulta Utilizzo di Amazon RDS Event Notification.

Nell'esempio seguente, vedremo come abilitare la replica da RDS a un DB esterno situato su un'istanza EC2.
Dovresti avere i log binari abilitati, qui utilizziamo uno slave RDS.

Specifica il numero di ore di conservazione dei log binari.

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

Su RDS MASTER, crea l'utente di replica con i seguenti comandi:

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

Su RDS SLAVE, esegui i comandi:

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

Su RDS SLAVE, esegui mysqldump con il seguente formato:

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

Importa il dump del DB in un database esterno:

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>;

Crea un filtro di replica per ignorare le tabelle create da AWS solo su RDS

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

Avvia la replica

START SLAVE;

Verifica lo stato della replica

SHOW SLAVE STATUS;

Per ora è tutto. La gestione di MySQL su AWS è un argomento importante. Facci sapere i tuoi pensieri nella sezione commenti qui sotto.