Sono un grande fan di AWS in generale ... ma RDS, non così tanto.
@RolandoMySQLDBA ha sottolineato che ci sono alcuni punti abbastanza positivi a riguardo.
L'unico vantaggio che vedo in RDS rispetto a MySQL su EC2 è la possibilità di eseguire snapshot point-and-click, cloni e ripristino point-in-time, ma questi non sono quasi sufficienti a compensare la perdita di controllo e flessibilità e sicuramente non giustifica il prezzo più alto. RDS è sexy in qualche modo, ma alla fine non puoi fidarti di ciò che non puoi risolvere, perché non puoi raggiungere tutte le parti in movimento.
Non mi piace non avere il SUPERprivilegio. Non mi piace non essere in grado di modificare il registro degli errori. Non mi piace non poter eseguire "top" o "iostat" sul mio server di database per vedere come i core e le unità godono del carico. Non mi piace non avere accesso al motore di archiviazione federato. Non mi piace l'idea di pagare per una macchina master di backup hot standyby (multi-AZ) che non posso nemmeno sfruttare come replica di lettura. Certo, ci sono spiegazioni perfettamente ragionevoli per cui tutti questi vincoli devono essere in atto affinché MySQL possa essere impacchettato e venduto con successo come RDBMS-in-a-box. L'unica cosa è che RDBMS-in-a-box "risolve" tutta una serie di problemi che non ho ... e si mette sulla mia strada, causando nuovi problemi.
Ma il patto assoluto per me con RDS è la completa mancanza di accesso ai registri binari e alla replica. I binlog, in particolare quelli basati su righe, sono un fantastico strumento di recupero per le catastrofi minori, ma non ti aiutano se non riesci ad accedervi. Vuoi configurare un server locale nel tuo ufficio come replica di lettura del tuo database di produzione in RDS? Qualcosa da cui prelevare backup locali, rapporti, avere a portata di mano per il ripristino di emergenza dovrebbe accadere qualcosa di impensabile ai dati che risiedono in RDS? È un'idea che è allo stesso tempo ovvia e geniale.
Spiacenti, l'accesso diretto alla replica non è disponibile. Certo, puoi pagare per le repliche lette ... ma solo come altre istanze RDS. Non è una proposta di valore nel mio libro.
Aggiornamento: una modifica significativa in RDS per MySQL 5.6
Preferisco ancora eseguire il mio server (anche in EC2) rispetto all'esecuzione di RDS per una serie di motivi, tra cui la mancanza di supporto per le funzioni definite dall'utente , l'impossibilità di utilizzare Federated Storage Engine e l'incapacità di avere quello connessione extra disponibile per l'accesso di emergenza ... tuttavia ...
Amazon ha apportato una modifica significativa in MySQL 5.6 per RDS che elimina una delle mie principali obiezioni - forse la mia più grande obiezione: i registri binari sono ora accessibili e puoi eseguire un'istanza non RDS come slave o collegare altre utility al server che legge il flusso binlog.
http://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/MySQL.Procedural.Exporting.NonRDSRepl.html
Ufficialmente, la documentazione indica che lo stanno esponendo in modo da poter impostare uno slave allo scopo di eseguire una migrazione in tempo reale: si sincronizza il server master futuro straniero dall'istanza RDS esistente utilizzando mysqldump, quindi lo si connette a RDS come slave per ottenere un feed live di aggiornamenti tramite il flusso di replica fino a quando la tua applicazione non viene migrata sul nuovo master, ma ufficiosamente puoi farlo su base continuativa purché non ti aspetti che ti supportino ... che, a me sembra ragionevole.
Ciò è stato confermato in un recente webinar , in una conversazione che inizia intorno alle 56:45:
"Puoi mantenerlo in uno stato replicato indefinitamente ...
"... fintanto che ti assumi la responsabilità di mantenere la replica ..."
"Non ti stiamo impedendo di eseguire la replica in corso se è quello che vuoi."
Questa nuova capacità mi è bastata a far cadere la mia obiezione generale sull'uso di RDS nelle nostre istanze MySQL a supporto di siti Web rivolte al pubblico, dove non usiamo FEDERATEDo alcune delle altre cose così o per niente.
Quindi non sono ancora a favore, ma non sono più contrario, poiché avere un flusso live dei registri binari mi riporta in ultima analisi al controllo dei dati in tempo reale e alla responsabilità di garantire che nessuna transazione sia perso in una catastrofica interruzione è tornato con me, perché io, come DBA, sono di nuovo in controllo - che è esattamente come lo voglio. Avere un fornitore di terze parti a cui puntare il dito, o presentare una causa, o qualsiasi altra cosa, non recupera i dati persi se scompare in un buco nero all'interno di una scatola nera.
Il management sembra apprezzare l '"idea" di RDS e non si oppone alla differenza di costo, quindi ora stiamo lanciando tutti i nuovi siti Web con RDS alle spalle.
Il recupero point-in-time point and click, lo ammetto, è una bella funzionalità di RDS ... non altera o interrompe la tua macchina esistente - invece, avvia un'istanza completamente nuova, usando il backup che era il più vicino nel tempo al momento selezionato, quindi applica i binlog necessari per portare la nuova macchina al punto nel tempo specificato.
In relazione a questo, ma nella direzione opposta, ora è anche possibile utilizzare una strategia simile per migrare un database MySQL live in RDS ... è possibile connettere un master RDS (presumibilmente, in genere, si tratterebbe di una nuova distribuzione istanza) come slave di un sistema esistente in modo che l'istanza RDS abbia la versione live dei dati al momento della migrazione. A differenza dell'accesso ai binlog RDS per la replica esterna, che funziona solo con 5.6, la replica interna è supportata in RDS a partire da 5.5.33 e 5.6.13.