No trabalho, hospedamos todos os nossos servidores da web no Amazon EC2 e geralmente usamos bancos de dados MySQL instalados na mesma caixa que o servidor da Apache e nos comunicamos com eles localhost. Agora, enfrentamos a necessidade de migrar nosso banco de dados para seu próprio servidor para um de nossos sistemas. Eu tenho uma escolha entre duas soluções: use o Amazon RDS ou simplesmente inicie uma nova caixa do Amazon EC2 e instale o MySQL nela.

O RDS, sendo um serviço de banco de dados dedicado fornecido pela mesma empresa que o EC2, parece ser a opção obviamente melhor . No entanto, quando observo o preço das duas opções (consulte http://aws.amazon.com/ec2/pricing e http://aws.amazon.com/rds/pricing ), parece que um servidor RDS custa quase o dobro de um servidor EC2 para uma caixa com as mesmas especificações.

Dado que sou capaz de lidar com backups sozinho e que o EC2 oferece a mesma capacidade de aumentar a instância conforme exigido pelo RDS, não vejo nenhum motivo para usar o RDS em vez do EC2. Parece que provavelmente estou perdendo algo grande, porque, se eu estivesse certo, ninguém usaria o RDS. O que exatamente estou perdendo e quais são as vantagens do RDS em instalar seu próprio banco de dados em uma instância do EC2?

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

O @RolandoMySQLDBA apontou alguns bons pontos contra ele.

A única vantagem que vejo no RDS em comparação ao MySQL no EC2 é a capacidade de apontar e clicar em snapshots, clones e recuperação point-in-time, mas elas não são suficientes para compensar a perda de controle e flexibilidade, e elas certamente não justifica que o preço seja mais alto. O RDS é sexy em alguns aspectos, mas você não pode confiar no que não pode consertar, porque não consegue acessar todas as partes móveis.

Eu não gosto de não ter o SUPERprivilégio. Eu não gosto de não conseguir seguir 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 de pagar por uma máquina principal de backup em espera (multi-AZ) que nem sequer posso aproveitar como réplica de leitura. Certamente, existem explicações perfeitamente razoáveis ​​para que todas essas restrições tenham que existir 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 entra no meu caminho, causando novos problemas.

Mas o ponto crucial para mim com o RDS é a completa falta de acesso aos logs binários e à replicação. Os binlogs, especialmente baseados em linhas, são uma ferramenta de recuperação fantástica para desastres menores, mas não ajudam em nada se você não puder acessá-los. Deseja configurar um servidor local no seu escritório como uma réplica de leitura do banco de dados de produção no RDS? Algo para obter backups locais, os relatórios têm em mãos para recuperação de desastres, caso algo impensável aconteça com seus dados que residem no RDS? Essa é uma ideia simultaneamente ó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 do RDS. Não é uma proposta de valor no meu livro.

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

Eu 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 a 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 ... no entanto ...

A Amazon fez uma alteração significativa no MySQL 5.6 para RDS que elimina uma das minhas principais objeções - talvez a 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 a finalidade de fazer uma migração ao vivo - você sincroniza o futuro servidor mestre estrangeiro da instância RDS existente usando mysqldumpe conecta-o ao RDS como 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 ajudem ... o que, para mim, parece razoável.

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

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

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

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

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

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 no controle dos dados em tempo real e na responsabilidade de garantir que nenhuma transação seja realizada. perdido em uma interrupção catastrófica está de volta comigo, porque eu, como o DBA, estou de volta ao controle - que é exatamente como eu quero. Ter um fornecedor terceirizado para apontar o dedo ou entrar com uma ação contra, ou o que seja, não recupera os dados perdidos se 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; portanto, estamos lançando todos os novos sites com o RDS por trás deles.

A recuperação point-in-time point-and-click, eu admito, é um recurso interessante no RDS ... não altera nem atrapalha sua máquina existente - em vez disso, inicia uma instância totalmente nova, usando o backup que foi mais próximo do ponto selecionado no tempo e, em seguida, aplica os binlogs necessários para levar a nova máquina para o ponto especificado.

Relacionado a isso, mas na outra direção, também é possível, agora, usar uma estratégia semelhante para migrar um banco de dados MySQL ao vivo para o RDS ... você pode conectar um mestre do RDS (presumivelmente, normalmente, esse seria um novo recurso implantado). exemplo) como escravo de um sistema existente para que a instância do RDS tenha a versão ao vivo dos dados no momento em que você migra para ele. Diferentemente do acesso aos binlogs do RDS para replicação externa, que funciona apenas na 5.6, a replicação interna é suportada no RDS, começando com 5.5.33 e 5.6.13.

Se o dimensionamento dos servidores de banco de dados não for a sua xícara de chá , é recomendável usar o Amazon RDS porque todos os sinos e assobios vêm com ele. Aqueles que simplesmente desejam HA moderado, backups e expansão se beneficiam bastante.

Por outro lado, se você deseja ampliar o hardware, isso está fora de questão para o RDS. E se você quiser aumentar as capacidades do MySQL? Infelizmente, isso está fora de questão para muitos aspectos que se deseja.

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 a seguinte tabela nessas 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 ao my.cnf. À luz disso, para alterar as my.cnfopções de inicialização, você deve primeiro criar uma Lista de Opções de Parâmetros de Banco de Dados baseada no MySQL e usar o RDS CLI (Command Line Interface)para alterar as Opções desejadas. Em seguida, 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 da 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âmetro do banco de dados MySettings
• Reinicie a instância do MySQL RDS

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

Se você deseja ampliar o MySQL, use o EC2. Em seguida, você pode my.cnftentar o que quiser, como sempre fez e está acostumado.