Sou um grande fã da AWS em geral ... mas RDS, nem tanto.

@RolandoMySQLDBA apontou alguns pontos muito bons contra ele.

A única vantagem que vejo no RDS em comparação com o MySQL no EC2 é a capacidade de apontar e clicar em instantâneos, clones e recuperação pontual, mas isso não é suficiente para compensar a perda de controle e flexibilidade e eles certamente não justifica o preço ser mais alto. O RDS é sexy em alguns aspectos, mas você não pode confiar no que não pode consertar, porque não pode acessar todas as partes móveis.

Não gosto de não ter o SUPERprivilégio. Não gosto de não poder rastrear o log de erros. Não gosto de não poder executar "top" ou "iostat" no meu servidor de banco de dados para ver como os núcleos e as unidades estão aproveitando a carga. Não gosto de não ter acesso ao mecanismo de armazenamento federado. Não gosto da ideia de pagar por uma máquina mestre de backup hot standyby (multi-AZ) que não posso nem usar como uma réplica de leitura. Claro, existem explicações perfeitamente razoáveis ​​de por que todas essas restrições devem estar em vigor para que o MySQL seja empacotado e vendido com sucesso como RDBMS-in-a-box. A única coisa é que o RDBMS-in-a-box "resolve" toda uma série de problemas que não tenho ... e atrapalha, causando novos problemas.

Mas o problema absoluto para mim com o RDS é a completa falta de acesso aos logs binários e à replicação. Os logs binários, especialmente baseados em linhas, são uma ferramenta de recuperação fantástica para pequenos desastres, mas não ajudam em nada se você não puder acessá-los. Deseja configurar um servidor local em seu escritório como uma réplica de leitura de seu banco de dados de produção no RDS? Algo para fazer backups locais, fazer relatórios, ter à mão para recuperação de desastres caso algo impensável aconteça com seus dados que residem no RDS? Essa é uma ideia ao mesmo tempo óbvia e brilhante.

Ops, desculpe, o acesso direto à replicação não está disponível. Claro, você pode pagar por réplicas de leitura... mas apenas como outras instâncias RDS. Não é uma proposta de valor no meu livro.

Atualização: uma mudança significativa no RDS para MySQL 5.6

Ainda prefiro executar meu próprio servidor (mesmo no EC2) em vez de executar o RDS por vários motivos, incluindo a falta de suporte para funções definidas pelo usuário , a incapacidade de usar o Federated Storage Engine e a incapacidade de ter o único conexão extra disponível para acesso de emergência... porém...

A Amazon fez uma mudança significativa no MySQL 5.6 para RDS que elimina uma das minhas principais objeções - talvez minha maior objeção: os logs binários agora estão acessíveis e você pode executar uma instância não RDS como escravo ou conectar outros utilitários ao servidor que lê o fluxo binlog.

http://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/MySQL.Procedural.Exporting.NonRDSRepl.html

Oficialmente, a documentação indica que eles estão expondo isso para que você possa configurar um escravo com o objetivo de fazer uma migração ao vivo - você sincroniza o futuro servidor mestre estrangeiro da instância RDS existente usando mysqldumpe, em seguida, conecta-o ao RDS como um escravo para obter um feed ao vivo de atualizações por meio do fluxo de replicação até que seu aplicativo seja migrado para o novo mestre - mas não oficialmente, você pode fazer isso continuamente, desde que não espere que eles o apoiem ... o que, para mim, parece razoável.

Isso foi confirmado em um Webinar recente , em uma conversa que começa por volta das 56h45:

"Você pode mantê-lo em um estado replicado indefinidamente...

"...desde que você assuma a responsabilidade de manter a replicação..."

"Não estamos impedindo você de fazer uma replicação contínua, se é isso que você deseja."

Esse novo recurso foi suficiente para eu deixar de lado minha objeção geral ao uso do RDS em nossas instâncias MySQL voltadas para o site voltadas para o público, onde não usamos FEDERATEDou algumas das outras coisas tanto ou nada.

Portanto, ainda não sou a favor, mas não sou mais contra, pois ter uma transmissão ao vivo dos logs binários me coloca de volta no controle dos dados em tempo real e na responsabilidade de garantir que nenhuma transação seja perdido em uma interrupção catastrófica está de volta comigo, porque eu, como o DBA, estou de volta no controle -- que é exatamente como eu quero. Ter um fornecedor terceirizado para apontar o dedo, ou abrir um processo contra, ou qualquer outra coisa, não recupera seus dados perdidos se eles desaparecerem em um buraco negro dentro de uma caixa preta.

A gerência parece gostar da "idéia" do RDS e não se opõe à diferença de custo, então estamos lançando todos os novos sites com o RDS por trás deles.

A recuperação point-in-time de apontar e clicar, admito, é um bom recurso no RDS... mais próximo no tempo para o ponto no tempo selecionado e, em seguida, aplica os binlogs necessários para trazer essa nova máquina para o ponto no tempo que você especificou.

Relacionado a isso, mas em outra direção, também é possível, agora, usar uma estratégia semelhante para migrar um banco de dados MySQL ativo para o RDS... instância) como escravo de um sistema existente para que a instância do RDS tenha a versão ativa dos dados no momento em que você migrar para ela. Ao contrário do acesso aos binlogs RDS para replicação externa, que só funciona em 5.6, a replicação interna é suportada no RDS começando com 5.5.33 e 5.6.13.

Se a expansão de servidores de banco de dados não for sua preferência , o Amazon RDS pode ser usado porque todos os sinos e assobios vêm com ele. Aqueles que simplesmente desejam HA moderado, backups e expansão se beneficiam muito.

Por outro lado, se você deseja aumentar o hardware, isso está fora de questão para o RDS. E se você quiser escalar os recursos do MySQL? Infelizmente, isso está fora de questão para muitos aspectos que alguém desejaria.

Por exemplo, você sabia que dois campos são limitados em todos os sete (7) modelos de servidor RDS?

• max_connections
• innodb_buffer_pool_size

Observe o gráfico a seguir sobre essas duas opções:

MODEL      max_connections innodb_buffer_pool_size
---------  --------------- -----------------------
t1.micro   34                326107136 (  311M)
m1-small   125              1179648000 ( 1125M,  1.097G)
m1-large   623              5882511360 ( 5610M,  5.479G)
m1-xlarge  1263            11922309120 (11370M, 11.103G)
m2-xlarge  1441            13605273600 (12975M, 12.671G)
m2-2xlarge 2900            27367833600 (26100M, 25.488G)
m2-4xlarge 5816            54892953600 (52350M, 51.123G)

Você não recebe o privilégio SUPER e não há acesso direto a arquivos my.cnf. Diante disso, para alterar my.cnfas opções de inicialização, você deve primeiro criar uma lista de opções de parâmetros de banco de dados baseada em MySQL e usar o RDS CLI (Command Line Interface)para alterar as opções desejadas. Então, você deve fazer isso para importar as novas opções:

• Crie um grupo de parâmetros de banco de dados personalizado (chame-o MySettings)
• Faça o download do RDS CLI e configure um arquivo de configuração com suas credenciais da AWS
• Execute o seguinte:./rds-modify-db-parameter-group MySettings --parameters "name=whateveroption,value=whatevervalue,method=immediate"
• Modificar usando a lista de opções de parâmetros do banco de dadosMySettings
• Reinicie a instância MySQL RDS

Usando uma API para atualizar uma única variável e fazer uma reinicialização obrigatória da instância do RDS para implementar a alteração? É um processo bastante doloroso ajustar qualquer opção.

Se você deseja escalar o MySQL, use o EC2. Então, você pode ajustar my.cnfao seu gosto, como sempre fez e está acostumado.