Perguntas frequentes sobre o Amazon RDS

Uma instância de banco de dados pode ser considerada como um ambiente de banco de dados na nuvem com os recursos computacionais e de armazenamento especificados. Você pode criar e excluir instâncias de banco de dados, definir e redefinir atributos de infraestrutura para as instâncias de banco de dados, além de controlar o acesso e a segurança usando o Console de Gerenciamento da AWS, as APIs do Amazon RDS e a CLI da AWS. Também é possível executar uma ou mais instâncias de banco de dados e cada instância pode oferecer suporte a um ou mais bancos de dados ou esquemas de banco de dados, dependendo do tipo de mecanismo.

As instâncias de banco de dados podem ser criadas facilmente usando o Console de Gerenciamento da AWS, as APIs do Amazon RDS ou a AWS Command Line Interface. Para executar uma instância de banco de dados usando o Console de Gerenciamento da AWS, clique em “RDS” e, em seguida, no botão “Launch DB Instance” (Executar instância de banco e dados) na guia Instances (Instâncias). Depois disso, você pode especificar os parâmetros para a instância de banco de dados, incluindo o mecanismo e a versão do banco de dados, o modelo da licença, o tipo de instância, o tipo e o volume de armazenamento, além das credenciais do usuário principal.

Também é possível alterar a política de retenção de backup da instância de banco de dados, a janela de backup preferencial e a janela de manutenção programada. Como alternativa, é possível criar a instância de banco de dados usando a API CreateDBInstance ou o comando create-db-instance.

Assim que a instância de banco de dados estiver disponível, você poderá recuperar o endpoint por meio da descrição da instância de banco de dados no Console de Gerenciamento da AWS, na API DescribeDBInstances ou utilizando o comando describe-db-instances. Usando esse endpoint, é possível estruturar a string de conexão exigida para se conectar diretamente à instância de banco de dados usando a ferramenta de banco de dados ou a linguagem de programação de sua preferência. Para permitir solicitações de rede na instância de banco de dados em execução, é necessário autorizar o acesso. Para obter detalhes sobre como estruturar e utilizar a string de conexão, consulte nosso Guia de conceitos básicos.

Por padrão, os clientes podem ter até um total de 40 instâncias de banco de dados do Amazon RDS. Dessas 40, até 10 podem ser instâncias de banco de dados RDS para Oracle ou RDS para SQL Server, sob o modelo de “Licença inclusa”. Todos os 40 podem ser usados para Amazon Aurora, RDS para PostgreSQL, RDS para MySQL, RDS para MariaDB e RDS para Oracle sob o modelo Bring Your Own License (BYOL). Observe que o RDS for SQL Server tem um limite de 100 bancos de dados em uma única instância de banco de dados. Para saber mais, consulte o Guia do usuário do Amazon RDS para SQL Server.

• RDS for Amazon Aurora: Sem limites impostos pelo software
• RDS for MySQL: Sem limites impostos pelo software
• RDS for MariaDB: Sem limites impostos pelo software
• RDS para Oracle: um banco de dados por instância; sem limites no número de esquemas por banco de dados imposto pelo software
• RDS para SQL Server: até 100 bancos de dados por instância
• RDS para PostgreSQL: Sem limites impostos pelo software
• RDS para Db2: até oito bancos de dados por instância

A seguir, há várias maneiras de importar dados para o Amazon RDS:

• MySQL: utilitários mysqldump ou mysqlimport
• Oracle: Data Pump, importar/exportar ou SQL Loader
• SQL Server: Assistente de importação/exportação, arquivos de backup completo (.bak) ou Bulk Copy Program (BCP)
• PostgreSQL: pg_dump

Para obter mais informações sobre importação e exportação de dados, consulte o Guia de importação de dados para MySQL, o Guia de importação de dados para Oracle, o Guia de importação de dados para SQL Server, o Guia de importação de dados para PostgreSQL ou o Guia de importação de dados para Db2.

Além disso, o AWS Database Migration Service pode ajudar você a migrar bancos de dados para a AWS com segurança.

A janela de manutenção do Amazon RDS é sua oportunidade de controlar quando ocorrem as modificações de instâncias de banco de dados, as atualizações de versão de mecanismo de banco de dados e a aplicação de patches de software, caso alguma dessas atividades seja solicitada ou exigida. Se um evento de manutenção estiver programado para uma determinada semana, ele será iniciado durante a janela de manutenção que você identificar.

Os eventos de manutenção que exigem que o Amazon RDS deixe a instância de banco de dados offline são: escalar operações computacionais (que geralmente levam poucos minutos do início ao fim), upgrades de versão do mecanismo de banco de dados ou a aplicação obrigatória de patches de software. A aplicação obrigatória de patches é programada automaticamente somente para patches relacionados à segurança e à resiliência. Essas aplicações de patches ocorrem com pouca frequência (normalmente uma vez a cada poucos meses) e raramente exigem mais do que uma fração de sua janela de manutenção.

Se você não especificar uma janela de manutenção semanal preferencial ao criar uma instância de banco de dados, um valor padrão de 30 minutos será atribuído. Se você quiser modificar quando a manutenção será realizada em seu nome, basta modificar a instância de banco de dados no Console de Gerenciamento da AWS, na API ModifyDBInstance ou usando o comando modify-db-instance. Cada uma das instâncias de banco de dados pode ter janelas de manutenção preferenciais diferentes, se assim for desejado.

A execução da instância de banco de dados como uma implantação Multi-AZ pode reduzir ainda mais o impacto de um evento de manutenção. Consulte o Guia do usuário do Amazon RDS para obter mais informações sobre operações de manutenção.

Para os bancos de dados de produção, recomendamos habilitar o monitoramento avançado, que fornece acesso a mais de 50 métricas de CPU, memória, sistema de arquivos e E/S de disco. Você pode habilitar esses recursos por instância e escolher a granularidade (que pode ser reduzida a até um segundo). Altos níveis de utilização da CPU podem reduzir a performance da consulta. Nesse caso, considere realizar a escalabilidade da sua classe de instância de banco de dados. Para obter mais informações sobre o monitoramento da instância de banco de dados, consulte o Guia do usuário do Amazon RDS.

Se você estiver usando o RDS para MySQL ou MariaDB, poderá acessar os logs de consulta lenta do banco de dados a fim de determinar se há consultas SQL de execução lenta e, em caso afirmativo, quais são as características de performance de cada uma. Você pode configurar o parâmetro de banco de dados “slow_query_log” e consultar a tabela mysql.slow_log para analisar as consultas SQL de execução lenta. Consulte o Guia do usuário do Amazon RDS para saber mais.

Se estiver usando o RDS for Oracle, será possível utilizar os dados de rastreamento de arquivo para identificar consultas lentas. Para obter mais informações sobre como acessar os dados do arquivo de rastreamento, consulte o Guia do usuário do Amazon RDS. 

Caso esteja usando o RDS for SQL Server, será possível utilizar rastreamentos do cliente do SQL Server para identificar consultas lentas. Para obter informações sobre como acessar os dados do arquivo de rastreamento do lado do servidor, consulte o Guia do usuário do Amazon RDS.

Para obter a lista das versões do mecanismo de banco de dados com suporte, consulte a documentação de cada mecanismo:

• Amazon Aurora
• Amazon RDS for PostgreSQL
• Amazon RDS para MySQL
• Amazon RDS for MariaDB
• Amazon RDS para SQL Server
• Amazon RDS para Oracle
• Amazon RDS para Db2

Consulte a página de perguntas frequentes sobre cada mecanismo de banco de dados do Amazon RDS para obter detalhes sobre a numeração de versões:

• Amazon RDS para MySQL
• Amazon RDS for MariaDB
• Amazon RDS for PostgreSQL
• Amazon RDS for Oracle
• Amazon RDS for SQL Server
• Amazon Aurora

Com o tempo, o Amazon RDS adiciona suporte para novas versões principais e secundárias dos mecanismos de banco de dados. O número de novas versões com suporte variará em função da frequência e do conteúdo das versões e dos patches do fornecedor ou da organização de desenvolvimento do mecanismo, bem como do resultado de uma verificação detalhada dessas versões e patches pela nossa equipe de engenharia de banco de dados. No entanto, como orientação geral, pretendemos oferecer compatibilidade com novas versões de mecanismo em até 5 meses após a sua disponibilidade geral.

Você pode especificar qualquer versão atualmente compatível (principal ou secundária) ao criar uma nova instância de banco de dados por meio da operação Executar instância de banco de dados no Console de Gerenciamento da AWS ou da API CreateDBInstance. Vale ressaltar que nem toda versão de mecanismos de banco de dados está disponível em todas as regiões da AWS.

O Amazon RDS se empenha para manter a instância de banco de dados atualizada fornecendo versões mais recentes dos mecanismos de bancos de dados compatíveis. Depois que uma nova versão de mecanismo de banco de dados é lançada pelo fornecedor ou pelo departamento de desenvolvimento, ela é testada minuciosamente pela nossa equipe de engenharia de banco de dados antes de ser disponibilizada no Amazon RDS.

Recomendamos que você mantenha a instância de banco de dados atualizada para a versão secundária mais recente, pois ela conterá as correções de segurança e de funcionalidade mais recentes. Diferentemente de outras atualizações de versão principal, as atualizações de versão secundária incluem apenas alterações retrocompatíveis com versões secundárias anteriores (da mesma versão principal) do mecanismo de banco de dados. 

Se uma nova versão secundária não contiver correções que beneficiem os clientes do Amazon RDS, é possível que ela não seja disponibilizada no Amazon RDS. Logo depois que uma nova versão secundária estiver disponível no Amazon RDS, a definiremos como a versão secundária preferencial para novas instâncias de banco de dados. 

Para atualizar manualmente uma instância de banco de dados para uma versão de mecanismo compatível, use o comando Modify DB Instance (Modificar instâncias de banco de dados) no Console de Gerenciamento da AWS ou a API ModifyDBInstance, e defina o parâmetro de versão de mecanismo do banco de dados para a versão desejada. Por padrão, a atualização será aplicada durante a próxima janela de manutenção. Você também pode optar por atualizar imediatamente, selecionando a opção Apply Immediately (Aplicar imediatamente) na API do console.

Se determinarmos que uma nova versão secundária de mecanismo contém correções de erros significativas em comparação com uma versão secundária lançada anteriormente, programaremos atualizações automáticas para instâncias de banco de dados cuja configuração “Auto Minor Version Upgrade” (Atualização automática de versão secundária) esteja definida como “Yes” (Sim). Essas atualizações serão programadas para que ocorram durante as janelas de manutenção especificadas pelo cliente.

Programamos essas atualizações para que você possa se planejar, pois é necessário um período de inatividade para atualizar uma versão de mecanismo de banco de dados, mesmo para instâncias multi-AZ. Se você desejar desativar as atualizações automáticas de versões secundárias, pode definir a configuração “Auto Minor Version Upgrade” (Atualização automática de versão secundária) como “No” (Não).

No caso do RDS para Oracle e do RDS para SQL Server, se a atualização para a próxima versão secundária exigir uma alteração para uma edição diferente, é provável que não possamos programar atualizações automáticas, mesmo se você tiver habilitado a configuração “Auto Minor Version Upgrade” (Atualização automática de versão secundária). A realização ou não da programação automática de atualizações nas situações mencionadas acima será determinada de acordo com cada caso.

Como as atualizações para versões principais envolvem algum risco de compatibilidade, elas não serão realizadas automaticamente e deverão ser inicializadas por você (exceto no caso de substituição de uma versão principal. Veja abaixo). Para obter mais informações sobre como atualizar uma instância de banco de dados para uma nova versão de mecanismo de banco de dados, consulte o Guia do usuário do Amazon RDS.

Sim. Isso também é possível criando um DB snapshot por meio da instância de banco de dados atual, restaurando o DB snapshot para criar uma nova instância de banco de dados e depois iniciando uma atualização de versão para a nova instância de banco de dados. Isso permite testar com segurança a cópia atualizada de sua instância de banco de dados antes de decidir se deseja ou não atualizar a instância de banco de dados original.

Para obter mais informações sobre como restaurar um DB Snapshot, consulte o Guia do usuário do Amazon RDS.

• Pretendemos oferecer compatibilidade com os lançamentos de versões principais (ex.: MySQL 5.6 e PostgreSQL 9.6) por pelo menos 3 anos após o início da compatibilidade com o Amazon RDS.
• Pretendemos oferecer a versões secundárias (por exemplo, MySQL 5.6.37 e PostgreSQL 9.6.1) por pelo menos um ano após o início do suporte pelo Amazon RDS.

Periodicamente, substituiremos versões principais e secundárias dos mecanismos. As versões principais são disponibilizadas pelo menos até o fim da vida útil da comunidade para a versão da comunidade correspondente ou até que a versão não receba mais correções de software ou atualizações de segurança. Para versões secundárias, a substituição ocorrerá quando uma versão secundária apresentar erros ou problemas de segurança significativos que foram resolvidos em uma versão secundária posterior.

Embora nos esforcemos para cumprir essas diretrizes, em alguns casos podemos deixar de usar versões principais ou secundárias específicas antecipadamente, como nos casos de problemas de segurança. No improvável cenário em que os casos mencionados acima possam vir a ocorrer, o Amazon RDS atualizará automaticamente o mecanismo do banco de dados para resolver o problema. Circunstâncias específicas podem determinar cronogramas diferentes dependendo do problema que estiver sendo resolvido.

Quando uma versão secundária de um mecanismo de banco de dados for substituída no Amazon RDS, forneceremos um período de três (3) meses após o anúncio antes de iniciar as atualizações automáticas. Ao final desse período, todas as instâncias que ainda estiverem executando a versão secundária substituída serão programadas para upgrade automático para a versão secundária mais recente com suporte durante as janelas de manutenção programadas.

Quando uma versão principal do mecanismo de banco de dados for substituída no Amazon RDS, forneceremos um período mínimo de seis (6) meses após o anúncio da substituição para que você inicie uma atualização para uma versão principal compatível. Ao final do período de carência, será realizado um upgrade automático de qualquer instância que ainda esteja executando a versão substituída durante as janelas de manutenção programadas.

Em alguns casos, podemos substituir versões principais ou secundárias específicas sem aviso prévio, como quando descobrimos que uma versão não está mais atendendo à nossa alta qualidade, performance ou nível de segurança. Na remota possibilidade de que tais casos ocorram, o Amazon RDS descontinuará a criação de novas instâncias de banco de dados e clusters com essas versões. Os clientes existentes ainda serão capazes de executar seus bancos de dados. Circunstâncias específicas podem determinar cronogramas diferentes dependendo do problema que estiver sendo resolvido.

Você paga apenas pelo que usa e não há taxas mínimas ou de configuração. Você é cobrado com base em:

• Horas de instância de banco de dados – baseadas na classe (ex.: db.t2.micro e db.m4.large) da instância de banco de dados utilizada. As horas de instância parciais de banco de dados são cobradas em incrementos de um segundo, com uma cobrança mínima de dez minutos após uma alteração de status faturável, como criar, iniciar ou modificar a classe da instância de banco de dados. Para obter mais detalhes, leia nosso anúncio de novidades.
• Armazenamento (por GB mensais): capacidade de armazenamento que você provisionou para a instância de banco de dados. Se você ajustar a escala da capacidade de armazenamento provisionada dentro do mês, sua fatura será rateada.
• Solicitações de E/S por mês: número total de solicitações de E/S de armazenamento que você receber (somente para o Amazon Aurora e o armazenamento magnético do Amazon RDS)
• IOPS provisionadas por mês: taxa de IOPS provisionadas, independentemente das IOPS utilizadas (somente para o armazenamento SSD de IOPS provisionadas do Amazon RDS)
• Armazenamento de backup – Armazenamento de backup é o armazenamento associado aos seus backups de bancos de dados automáticos e a qualquer snapshot de banco de dados iniciado pelo cliente. Aumentar seu período de retenção de backup ou fazer snapshots de bancos de dados adicionais aumenta o armazenamento de backup utilizado por seu banco de dados.
• Transferência de dados: transferência de dados da Internet que entram e saem da instância de banco de dados.

Para obter informações sobre os preços do Amazon RDS, visite a seção de preços na página do produto Amazon RDS.

A cobrança de uma instância de banco de dados é iniciada a partir do momento em que a instância estiver disponível. A cobrança continua até que a instância de banco de dados seja encerrada, o que pode ocorrer após sua exclusão ou caso ocorra falha na instância.

As horas da instância de banco de dados são cobradas por cada hora em que a instância de banco de dados estiver sendo executada em um estado disponível. Se você não desejar continuar sendo cobrado pela instância de banco de dados, deverá interrompê-la ou excluí-la para evitar ser faturado por horas adicionais da instância. As horas parciais da instância de banco de dados utilizadas são cobradas em incrementos de um segundo, com uma cobrança mínima de dez minutos após uma alteração do estado faturável, como criação, inicialização ou modificação da classe de instância de banco de dados.

Enquanto a instância de banco de dados estiver parada, você será cobrado pelo armazenamento provisionado (incluindo Provisioned IOPS) e pelo armazenamento de backup (incluindo snapshots manuais e backups automatizados dentro da janela de retenção especificada), mas não pelas horas de instância de banco de dados.

O armazenamento de backup gratuito é fornecido até o limite do armazenamento total do banco de dados provisionado da sua conta em toda a região. Por exemplo, se você tiver uma instância de banco de dados MySQL com 100 GB de armazenamento provisionado ao longo do mês e uma instância de banco de dados PostgreSQL com 150 GB de armazenamento provisionado ao longo do mês, ambas na mesma região e na mesma conta, forneceremos 250 GB de armazenamento de backup nessa conta e região sem custo adicional. Você só será cobrado pelo armazenamento de backup que exceder essa quantidade.

A cada dia, o armazenamento de banco de dados provisionado total da sua conta na região é comparado com o armazenamento de backup total na região, e apenas o armazenamento de backup em excesso é cobrado. Por exemplo, se você tiver exatamente 10 GB de armazenamento de backup em excesso todos os dias, será cobrado por 10 GB mensais de armazenamento de backup no mês. Se você tiver 300 GB de armazenamento provisionado por dia e 500 GB de armazenamento de backup por dia, mas apenas durante metade do mês, será cobrado por apenas 100 GB de armazenamento de backup no mês (não 200 GB no mês), pois a cobrança é calculada diariamente (proporcional), e os backups não existiram durante todo o mês. Observe que o armazenamento de backup gratuito é específico da conta e da região.

O tamanho dos backups é diretamente proporcional à quantidade de dados em sua instância. Por exemplo, se você tiver uma instância de banco de dados com 100 GB de armazenamento provisionado, mas armazenar apenas 5 GB de dados nela, seu primeiro backup terá aproximadamente 5 GB (não 100 GB). Os backups subsequentes são incrementais e armazenarão apenas os dados alterados na instância de banco de dados. Observe que o tamanho do armazenamento de backup não é exibido no console do RDS ou na resposta da API DescribeDBSnapshots.

O armazenamento provisionado à instância de banco de dados para os dados principais está localizado em uma única zona de disponibilidade. Ao realizar o backup do banco de dados, os dados de backup (incluindo logs de transações) são replicados com redundância geográfica em várias zonas de disponibilidade para fornecer níveis ainda maiores de durabilidade dos dados. O preço para armazenamento de backup além de sua alocação grátis reflete essa replicação extra que ocorre para maximizar a durabilidade de seus backups críticos.

Se você especificar que a instância de banco de dados deve ser uma implantação Multi-AZ, a cobrança será feita de acordo com o preço Multi-AZ publicado na página de preços do Amazon RDS. O faturamento de Multi-AZ se baseia no seguinte:

• Horas da instância de banco de dados Multi-AZ: com base na classe (por exemplo, db.t2.micro e db.m4.large) da instância de banco de dados utilizada. Assim como nas implantações padrões em uma única zona de disponibilidade, as horas parciais da instância de banco de dados utilizadas são cobradas em incrementos de um segundo, com uma cobrança mínima de dez minutos após uma alteração de estado cobrável, como criação, inicialização ou modificação da classe de instância de banco de dados. Se você converter a implantação de instância de banco de dados de padrão para Multi-AZ dentro do período de uma hora, ambas as taxas aplicáveis por aquela hora serão cobradas.
• Armazenamento provisionado (para instância de banco de dados Multi-AZ) – Se você converter a implantação de padrão para Multi-AZ em um período de uma hora, a taxa de armazenamento aplicável mais alta para aquela hora será cobrada.
• Solicitações de E/S por mês – Número total de solicitações de E/S que você possuir. Implantações Multi-AZ utilizam um volume maior de solicitações de E/S do que implantações de instância de banco de dados padrão, dependendo da taxa de gravação/leitura de banco de dados. Uso de gravação de E/S associado com atualizações de banco de dados será duplicado enquanto o Amazon RDS replica seus dados em sincronia para a instância de banco de dados em espera. O uso de leitura de E/S permanecerá igual.
• Armazenamento de backup – O uso do armazenamento de backup não mudará, independentemente de a instância de banco de dados ser padrão ou ser uma implantação Multi-AZ. Os backups simplesmente serão retirados da espera para evitar suspensão de E/S na instância de banco de dados principal.
• Transferência de dados – Você não será cobrado pela transferência de dados resultante da replicação de dados entre seu modo principal e o modo de espera. A transferência de dados da Internet para dentro e para fora da instância de banco de dados terá o mesmo valor cobrado pela implantação padrão.

Salvo indicação em contrário, nossos preços excluem impostos e taxas aplicáveis, incluindo o IVA e o imposto de vendas aplicável. Para clientes com endereço para cobrança no Japão, o uso da AWS está sujeito ao imposto sobre consumo japonês. Saiba mais.

O nível gratuito da AWS para o Amazon RDS oferece o uso gratuito de microinstâncias de banco de dados mono-AZ que executam MySQL, MariaDB, PostgreSQL e SQL Server Express Edition. O nível de uso gratuito é limitado a 750 horas de instâncias por mês. Os clientes também recebem gratuitamente 20 GB de armazenamento de banco de dados de uso geral (SSD) e 20 GB por mês de armazenamento de backup.

As novas contas da AWS recebem 12 meses de acesso ao nível gratuito da AWS. Consulte as Perguntas frequentes sobre o nível gratuito da AWS para obter mais informações.

Sim. Você pode executar mais de uma instância micro de banco de dados Single-AZ simultaneamente e estar qualificado para utilização no nível gratuito da AWS para o Amazon RDS. No entanto, qualquer uso que exceda 750 horas de instância em todas as instâncias micro de banco de dados Single-AZ do Amazon RDS e em todos os mecanismos de banco de dados e regiões elegíveis será cobrado pelo preço padrão do Amazon RDS.

Por exemplo, se você executar duas instâncias micro de banco de dados Single-AZ por 400 horas cada em um mês, acumulará 800 horas de utilização de instâncias, das quais 750 horas serão gratuitas. As 50 horas restantes serão cobradas pelo preço padrão do Amazon RDS.

Não. Um cliente com acesso ao nível gratuito da AWS pode usar até 750 horas de instância para microinstâncias que estão sendo executadas pelo MySQL, PostgreSQL ou SQL Server Express Edition. Qualquer uso que exceda 750 horas de instância, em todas as microinstâncias de banco de dados Single-AZ do Amazon RDS e em todos os mecanismos e regiões de banco de dados qualificados, será cobrado de acordo com os preços padrão do Amazon RDS.

Você é cobrado pelo preço padrão do Amazon RDS pelas horas de instância utilizadas além do que o nível gratuito oferece. Consulte a página de preços do Amazon RDS para obter mais detalhes.

As instâncias reservadas do Amazon RDS permitem que você reserve uma instância de banco de dados por um período de vigência de um ou três anos e, em troca, receba um desconto considerável em comparação ao preço de instâncias sob demanda para a instância de banco de dados. Existem três opções de pagamento de instâncias reservadas (sem pagamento adiantado, pagamento adiantado parcial e pagamento adiantado integral). Essas opções permitem estabelecer um equilíbrio entre o valor pago antecipadamente e o preço por hora efetivo.

Em termos de funcionalidade, as instâncias reservadas e as instâncias de banco de dados sob demanda são exatamente as mesmas. A única diferença está em como as instâncias de banco de dados são cobradas. Com as instâncias reservadas, você compra uma reserva de um ou três anos e, em troca, recebe uma taxa efetiva de uso por hora mais baixa (em comparação às instâncias de banco de dados sob demanda) durante o período de vigência. A menos que você tenha comprado instâncias reservadas em uma região, todas as instâncias de banco de dados serão cobradas de acordo com as taxas por hora sob demanda.

É possível comprar uma instância reservada na seção “Reserved Instance” (Instância reservada) do Console de Gerenciamento da AWS do Amazon RDS. Como alternativa, você pode usar a API do Amazon RDS ou a AWS Command Line Interface para listar as reservas disponíveis para compra e, em seguida, comprar uma reserva de instância de banco de dados.

Após realizar uma compra reservada, o uso de uma instância de banco de dados reservada será igual ao de uma instância de banco de dados sob demanda. Você pode executar uma instância de banco de dados usando a classe, o mecanismo e a região semelhantes aos da instância para a qual fez a reserva. Enquanto a sua compra de reserva estiver ativa, o Amazon RDS aplicará a taxa por hora reduzida à qual você tem direito para a nova instância de banco de dados.

As instâncias reservadas do Amazon RDS são compradas para uma região em vez de para uma zona de disponibilidade específica. Como as instâncias reservadas não são específicas de uma zona de disponibilidade, elas não são reservas de capacidade. Isso significa que mesmo se a capacidade estiver limitada em uma zona de disponibilidade, as reservas ainda poderão ser compradas na região e o desconto será aplicado para corresponder ao uso em qualquer zona de disponibilidade na região em questão.

É possível adquirir até 40 instâncias de banco de dados reservadas. Se quiser executar mais de 40 instâncias de banco de dados, preencha o formulário de solicitação da instância de banco de dados do Amazon RDS.

Basta comprar uma reserva de instância de banco de dados com a mesma classe de instância de banco de dados, o mesmo mecanismo de banco de dados, a mesma opção Multi-AZ e o mesmo modelo de licença dentro da mesma região que a instância de banco de dados que você está executando atualmente e que gostaria de reservar. Se a compra da reserva for bem sucedida, o Amazon RDS aplicará automaticamente a nova cobrança de uso por hora para a instância de banco de dados atual.

As mudanças de preço associadas a uma instância reservada são ativadas após o recebimento da solicitação, enquanto a autorização de pagamento é processada. Acompanhe o status da sua reserva na página de atividade da conta da AWS ou usando a API DescribeReservedDBInstances ou o comando describe-reserved-db-instances. Se o pagamento único não for autorizado com sucesso até o período da próxima fatura, o preço descontado não terá efeito.

Quando o período da reserva expirar, a instância reservada será revertida para a taxa de uso por hora sob demanda correspondente à classe e à região da instância de banco de dados.

As operações do Amazon RDS para criar, modificar e excluir instâncias de banco de dados não fazem distinção entre instâncias sob demanda e reservadas. Ao calcular o faturamento, o sistema aplicará suas reservas para que todas as instâncias de banco de dados qualificadas sejam cobradas com a menor taxa por hora de instância de banco de dados reservada.

Cada reserva está associada ao seguinte conjunto de atributos: mecanismo de banco de dados, classe de instância de banco de dados, tipo de implantação Multi-AZ, modelo de licença e região.

Uma reserva de um mecanismo e um modelo de licença de banco de dados qualificado para flexibilidade de tamanho (MySQL, MariaDB, PostgreSQL, Amazon Aurora ou Oracle “Traga sua própria licença”) será aplicada automaticamente a uma instância de banco de dados em execução de qualquer tamanho dentro da mesma família de instâncias (por exemplo, M4, T2 ou R3) para o mesmo mecanismo de banco de dados e a mesma região. Além disso, a reserva também será aplicada a instâncias de banco de dados executadas com as opções de implantação Single-AZ ou Multi-AZ.

Por exemplo, vamos supor que você comprou uma reserva de MySQL em uma instância db.m4.2xlarge. Se você decidir aumentar a escala da instância de banco de dados em execução para db.m4.4xlarge, a taxa com desconto dessa instância reservada cobrirá metade do uso da instância de banco de dados maior.

Se você estiver executando um mecanismo ou modelo de licença de banco de dados não qualificado para a flexibilidade de tamanho (“licença inclusa” do Microsoft SQL Server ou da Oracle), cada reserva poderá ser aplicada apenas a uma instância de banco de dados com os mesmos atributos durante o período de vigência. Se você decidir modificar algum desses atributos da instância de banco de dados em execução antes do término do período da reserva, as taxas de uso por hora dessa instância de banco de dados serão revertidas para as taxas por hora sob demanda.

Para obter mais detalhes sobre a flexibilidade de tamanho, consulte o Guia do usuário do Amazon RDS.

Cada instância reservada está associada a uma região específica, que é determinada por toda a duração da reserva e não pode ser alterada. Contudo, cada reserva pode ser usada em qualquer uma das zonas de disponibilidade encontradas dentro da região associada.

Sim. Quando você compra uma instância reservada, pode selecionar a opção Multi-AZ na configuração da instância de banco de dados disponível para compra. Além disso, se você estiver usando um mecanismo e um modelo de licença de banco de dados que ofereça suporte à flexibilidade de tamanho da instância reservada, uma instância reservada multi-AZ cobrirá o uso de duas instâncias de banco de dados mono-AZ.

Uma reserva de instância de banco de dados pode ser aplicada a uma réplica de leitura, desde que a classe e a região das instâncias de bancos de dados sejam as mesmas. Ao calcular sua conta, nosso sistema automaticamente aplicará as reservas para que todas as instâncias de banco de dados dessa categoria sejam cobradas com a taxa mais baixa por hora da instância reservada.

Não é possível cancelar a instância de banco de dados reservada, e o pagamento único (se for o caso) não é reembolsável. Você continuará a pagar por cada hora durante o período da instância de banco de dados reservada, independentemente da utilização.

Quando você compra uma IR com a opção de pagamento adiantado integral, paga por todo o período de vigência da IR em um único pagamento adiantado. Você pode optar por não pagar nada adiantado escolhendo a opção sem pagamento adiantado. O valor total da IR sem pagamento adiantado é distribuído por todas as horas do período de vigência e você será cobrado por hora do período, independentemente do uso. A opção de pagamento adiantado parcial é híbrido das opções de pagamento adiantado integral e sem pagamento adiantado. Você faz um pequeno pagamento adiantado e é cobrada uma taxa baixa por cada hora do período de vigência, independentemente do uso.

Para selecionar a classe de instância de banco de dados inicial e a capacidade de armazenamento você deverá avaliar as necessidades de computação, memória e armazenamento de sua aplicação. Para obter informações sobre as classes de instâncias de banco de dados disponíveis, consulte o Guia do usuário do Amazon RDS.

Você pode escalar os recursos computacionais e a capacidade de armazenamento alocados para sua instância de banco de dados com o Console de Gerenciamento da AWS (selecionando a instância de banco de dados desejada e clicando no botão Modificar), a API do Amazon RDS ou a CLI da AWS. Recursos de memória e de CPU são modificados ao alterar sua classe de instância de banco de dados e o armazenamento disponível é modificado ao alterar sua alocação de armazenamento. 

Leve em consideração que, ao modificar sua classe de instância de banco de dados ou seu armazenamento alocado, suas alterações solicitadas serão aplicadas durante a janela de manutenção especificada. Outra opção é usar o marcador “aplicar imediatamente” para aplicar imediatamente suas solicitações de escalabilidade. Lembre-se de que qualquer outra alteração pendente do sistema também será aplicada.

Algumas instâncias mais antigas do RDS para SQL Server podem não estar qualificadas para armazenamento dimensionado. Consulte as Perguntas frequentes do RDS para SQL Server para obter mais informações.

O Amazon RDS utiliza volumes do EBS para armazenamento de banco de dados e de log. Dependendo do tamanho do armazenamento solicitado, o Amazon RDS automaticamente cruza múltiplos volumes do EBS para aprimorar a performance de IOPS. No MySQL e na Oracle, para uma instância de banco de dados existente, você poderá observar uma melhoria na capacidade de E/S se aumentar a escala do armazenamento verticalmente. Você pode escalar a capacidade de armazenamento alocada para a instância de banco de dados usando o Console de Gerenciamento da AWS, a API ModifyDBInstance ou o comando modify-db-instance.

Para obter mais informações, consulte Armazenamento para o Amazon RDS.

A capacidade de armazenamento alocada para a instância de banco de dados pode ser expandida ao mesmo tempo em que a disponibilidade da instância de banco de dados é mantida. No entanto, ao decidir aumentar ou reduzir os recursos computacionais disponíveis para a instância de banco de dados, o banco de dados ficará temporariamente indisponível enquanto a classe de instância de banco de dados é modificada. Esse período de indisponibilidade geralmente tem duração de apenas alguns minutos e ocorrerá durante a janela de manutenção da instância de banco de dados, a não ser que você especifique que a modificação deva ser aplicada imediatamente.

O Amazon RDS é compatível com várias classes de instância de banco de dados e alocações de armazenamento para atender às diferentes necessidades dos aplicativos. Caso a aplicação necessite de mais recursos computacionais do que a maior classe de instância de banco de dados ou mais armazenamento do que a alocação máxima, será possível implementar partições, distribuindo os dados entre várias instâncias de banco de dados.

O armazenamento de uso geral (SSD) do Amazon RDS é adequado para uma ampla variedade de workloads de banco de dados com requisitos de E/S moderados. Com uma linha de base de 3 IOPS/GB e a capacidade de intermitência de até 3.000 IOPS, esta opção de armazenamento oferece desempenho previsível para atender às necessidades da maioria dos aplicativos.

O armazenamento de IOPS provisionadas (SSD) do Amazon RDS é uma opção de armazenamento baseado em SSD e projetada para oferecer performance de E/S rápida, previsível e consistente. Com o armazenamento de IOPS provisionadas (SSD) do Amazon RDS, você especifica uma taxa de IOPS ao criar uma instância de banco de dados e o Amazon RDS provisiona essa taxa de IOPS durante a vida útil da instância de banco de dados. O armazenamento de IOPS provisionadas (SSD) do Amazon RDS é otimizado para workloads de banco de dados transacionais (OLTP) com uso intensivo de E/S. Para obter mais detalhes, consulte o Guia do usuário do Amazon RDS.

O armazenamento magnético do Amazon RDS é útil para pequenas workloads de banco de dados, nas quais o acesso aos dados ocorre com menos frequência. O armazenamento magnético não é recomendado para instâncias de banco de dados de produção.

Escolha o tipo de armazenamento mais adequado para a sua carga de trabalho.

• Workloads OLTP de alta performance: armazenamento de IOPS provisionadas (SSD) do Amazon RDS
• Cargas de trabalho de banco de dados com requisitos moderados de E/S: armazenamento de propósito geral (SSD) do Amazon RDS

As IOPS com suporte do Amazon RDS variam por mecanismo de banco de dados. Para obter mais detalhes, consulte o Guia do usuário do Amazon RDS.

O Amazon RDS fornece dois métodos diferentes para fazer backup e restaurar instâncias de banco de dados: os backups automatizados e os snapshots de banco de dados (DB Snapshots).

O atributo de backup automatizado do Amazon RDS possibilita a recuperação a um ponto anterior no tempo da instância de banco de dados. Ao ativar backups automatizados para a instância de banco de dados, o Amazon RDS automaticamente realiza um snapshot diário completo dos dados (durante a janela de backup preferencial) e captura os logs de transações (à medida que as instâncias de banco de dados são atualizadas). Ao iniciar a recuperação point-in-time, os logs de transação serão aplicados ao backup diário mais apropriado para restaurar sua instância de banco de dados para o momento específico solicitado. 

O Amazon RDS retém backups de uma instância de banco de dados por um período específico definido pelo usuário, chamado de período de retenção que, como padrão, é de sete dias, mas pode ser configurado para até 35 dias. Você pode iniciar a restauração point-in-time e especificar qualquer segundo durante seu período de retenção, até o último momento restaurável. É possível usar a API DescribeDBInstances para retornar o momento recuperável mais recente da instância de banco de dados, que geralmente ocorre nos últimos cinco minutos. 

Outra opção para encontrar o momento recuperável mais recente de uma instância de banco de dados é selecioná-lo no Console de Gerenciamento da AWS e procurar na guia “Description” (Descrição) no painel inferior do console.

Os snapshots de banco de dados são iniciados pelo usuário e permitem fazer o backup da instância de banco de dados em um estado conhecido e com a frequência desejada para depois fazer a recuperação para o estado específico mencionado a qualquer momento. Os snapshots de banco de dados podem ser criados com o Console de Gerenciamento da AWS, a API CreateDBSnapshot ou o comando create-db-snapshot e serão mantidos até que você os exclua explicitamente.

Os snapshots que o Amazon RDS executa para habilitar backups automáticos estão disponíveis para cópia (usando o Console da AWS ou o comando copy-db-snapshot) ou para a funcionalidade de restauração de snapshot. Você pode identificá-los usando o tipo de snapshot “automatizado”. Além disso, é possível identificar a hora na qual o snapshot foi criado, visualizando o campo “Snapshot Created Time”. 

Como alternativa, o identificador dos snapshots "automáticos" também contêm a hora (no fuso horário UTC) na qual o snapshot foi criado.

Atenção: ao realizar uma operação de restauração para um momento exato (point-in-time) ou por meio de um DB snapshot, uma nova instância de banco de dados será criada com um novo endpoint (se desejar, a antiga instância de banco de dados poderá ser excluída). Isso é feito para permitir que você crie várias instâncias de banco de dados por meio de um DB snapshot específico ou um momento exato (point-in-time).

Por padrão, o Amazon RDS permite backups automáticos da sua instância de banco de dados com um período de retenção de sete dias. Se você deseja modificar o período de retenção do backup, pode fazer isso usando o console do RDS, a API CreateDBInstance (ao criar uma nova instância de banco de dados) ou a API ModifyDBInstance (para instâncias existentes). É possível usar esses métodos para alterar o parâmetro RetentionPeriod para qualquer número entre 0 (que desabilitará os backups automatizados) e o número de dias desejado, até 35. O valor não pode ser definido como 0 se a instância de banco de dados é uma origem para as réplicas de leitura. Para obter mais informações sobre backups automatizados, consulte o Guia do usuário do Amazon RDS.

A janela de backup preferencial é o período definido pelo usuário durante o qual é feito o backup de sua instância de banco de dados. O Amazon RDS utiliza esses backups de dados periódicos em conjunto com seus logs de transação para permitir que você restaure sua instância de banco de dados para qualquer segundo durante seu período de retenção, até o LatestRestorableTime (geralmente até os últimos minutos). Durante a janela de backup, a E/S de armazenamento pode ser suspensa brevemente enquanto o processo de backup inicializa (geralmente em alguns segundos). É possível que ocorra um breve período de aumento na latência. Não há período de suspensão de E/S para implantações Multi-AZ, visto que o backup é feito por meio do modo de espera.

Os backups automatizados de banco de dados e os DB Snapshots do Amazon RDS são armazenados no S3.

Você pode usar o Console de Gerenciamento da AWS, a API ModifyDBInstance ou o comando modify-db-instance para gerenciar o período de retenção dos backups automatizados, modificando o parâmetro RetentionPeriod. Se você quiser desativar completamente os backups automatizados, poderá configurar o período de retenção para 0 (não recomendado). É possível gerenciar os snapshots de banco de dados criados pelo usuário na seção “Snapshots” do console do Amazon RDS. Também é possível ver uma lista de snapshots dos banco de dados criados pelo usuário para uma instância de banco de dados específica usando a API DescribeDBSnapshots ou o comando describe-db-snapshots e excluindo os snapshots usando a API DeleteDBSnapshot ou o comando delete-db-snapshot.

É normal ter um ou dois DB snapshots automatizados a mais que o número de dias do período de retenção. Um snapshot automatizado extra é retido para garantir a capacidade de executar uma restauração point-in-time para qualquer momento durante o período de retenção.

Por exemplo, se a janela de backup for definida como um dia, serão necessários dois snapshots automatizados para oferecer suporte a restaurações para qualquer momento dentro das 24 horas anteriores. Outro snapshot automatizado pode existir, pois um novo snapshot automatizado é sempre criado antes da exclusão do snapshot automatizado mais antigo.

Quando você exclui uma instância de banco de dados, poderá criar um DB snapshot final após a exclusão. Nesse caso, poderá usar esse DB snapshot para restaurar posteriormente a instância de banco de dados excluída. Após a exclusão da instância de banco de dados, o Amazon RDS reterá esse DB snapshot juntamente com todos os outros DB snapshots criados manualmente. Consulte a página de preços para obter detalhes dos custos de armazenamento de backup.

Os backups automatizados serão excluídos quando a instância de banco de dados for excluída. Somente snapshots de banco de dados criados manualmente serão retidos após a instância de banco de dados ser excluída.

A Amazon VPC permite que você crie um ambiente de rede virtual em uma seção privada e isolada da Nuvem AWS, na qual poderá exercer controle total sobre aspectos como intervalos de endereços IP privados, sub-redes, tabelas de roteamento e gateways de rede. Com a Amazon VPC, você pode definir uma topologia de rede virtual e personalizar a configuração da rede para que ela se assemelhe a uma rede IP tradicional, que poderá ser operada em seu próprio datacenter.

Uma das maneiras de usar a VPC é quando você quer executar uma aplicação Web voltada ao público, mantendo os servidores de back-end em uma sub-rede privada sem acesso público. Você pode criar uma sub-rede pública para seus servidores web que têm acesso à Internet, e colocar as suas instâncias de banco de dados do Amazon RDS de backend em uma sub-rede privada. Para obter mais informações sobre a Amazon VPC, consulte o Guia do usuário da Amazon Virtual Private Cloud.

Se a sua conta da AWS foi criada antes de 04/12/2013, pode ser possível executar o Amazon RDS em um ambiente Amazon Elastic Compute Cloud (EC2)-Classic. A funcionalidade básica do Amazon RDS é a mesma para ambientes EC2-Classic ou EC2-VPC. O Amazon RDS gerencia backups, correções de software, detecção e recuperação de erros automáticas, réplicas de leitura, seja suas instâncias de banco de dados implantadas dentro ou fora de uma VPC. Para obter mais informações sobre as diferenças entre o EC2-Classic e o EC2-VPC, consulte a documentação do EC2.

Um grupo de sub-redes de banco de dados é uma coleção de sub-redes que você pode designar para as instâncias de banco de dados do Amazon RDS em uma VPC. Cada grupo de sub-redes de banco de dados deve ter, no mínimo, uma sub-rede para cada zona de disponibilidade em uma determinada região. Ao criar uma instância de banco de dados em uma VPC, você precisará selecionar um grupo de sub-redes de banco de dados. O Amazon RDS utiliza esse grupo de sub-redes de banco de dados e sua zona de disponibilidade preferencial para selecionar uma sub-rede e um endereço IP naquela sub-rede. O Amazon RDS cria e associa uma interface de rede elástica para sua Instância de Banco de Dados com esse endereço de IP.

Observe que é altamente recomendado que você use o nome do DNS para se conectar à instância de banco de dados, pois o endereço IP subjacente pode ser alterado (por exemplo, durante um failover).

Para implantações multi-AZ, a definição de uma sub-rede para todas as zonas de disponibilidade em uma região permitirá ao Amazon RDS criar um novo banco de dados em espera em outra zona de disponibilidade, caso seja necessário. Você precisa fazer isso mesmo para implementações Single-AZ, caso queira convertê-las em implementações Multi-AZ em algum momento.

Para ver um procedimento que orienta você nesse processo, consulte Criar uma instância de banco de dados em uma VPC no Guia do usuário do Amazon RDS.

Visite a seção Grupos de segurança do Guia do usuário do Amazon RDS para saber mais sobre as diferentes maneiras de controlar o acesso às suas instâncias de banco de dados.

Instâncias de banco de dados implantadas em uma VPC podem ser acessadas por instâncias do EC2 implantadas na mesma VPC. Caso essas instâncias de EC2 estejam implantadas em uma sub-rede pública com IPs elásticos associados, você poderá acessar as instâncias de EC2 por meio da Internet. As instâncias de banco de dados implantadas em uma VPC podem ser acessadas através da Internet ou de instâncias do EC2 externas à VPC utilizando uma VPN ou bastion hosts, que você pode executar em sua sub-rede pública, ou pela opção Acessível publicamente do Amazon RDS:

• Para usar um bastion host, você precisará configurar uma sub-rede pública com uma instância do EC2 que atue como um SSH Bastion. Essa sub-rede pública deve ter um gateway da Internet e regras de roteamento que permitam que o tráfego seja direcionado utilizando o host SSH, o qual deve encaminhar solicitações para o endereço IP privado de sua instância de banco de dados do Amazon RDS.
• Para usar conectividade pública, basta criar suas instâncias de banco de dados com a opção publicamente acessível definida como sim. Com a opção publicamente acessível ativa, as suas instâncias de banco de dados de uma VPC estarão totalmente acessíveis de fora da VPC por padrão. Isso significa que você não precisa configurar uma VPN ou um bastion host para permitir o acesso às suas instâncias.

Você também pode configurar um gateway de VPN que estenda sua rede corporativa para sua VPC, e permita o acesso para a instância de banco de dados do Amazon RDS naquele VPC. Consulte o Guia do usuário da Amazon VPC para obter mais detalhes.

Observe que é altamente recomendável que você use um nome de DNS para conectar com sua Instância de Banco de Dados conforme o endereço de IP subjacente pode ser alterado (p.ex., durante um failover).

Se a sua instância de banco de dados não estiver localizada em uma VPC, será possível usar o Console de Gerenciamento da AWS para transferir facilmente a instância de banco de dados para a VPC. Consulte o Guia do usuário do Amazon RDS para obter mais detalhes. Você pode também criar um snapshot da sua instância de banco de dados fora da VPC e restaurá-la na VPC ao especificar o grupo de sub-rede de banco de dados que você deseja usar. Como alternativa, você também pode realizar a operação "Restore to Point in Time".

A migração de instâncias de banco de dados da VPC interna para externa não é compatível. Por motivos de segurança, um snapshot de banco de dados de uma instância de banco de dados da VPC interna não pode ser restaurado para a VPC externa. O mesmo se aplica à funcionalidade de restauração para point-in-time. 

Você é responsável por modificar as tabelas de roteamento e as ACLs de rede em sua VPC para garantir que a instância de banco de dados seja acessível usando as instâncias de cliente na VPC. Para implantações multi-AZ, após um failover, a instância de cliente do EC2 e a instância de banco de dados do Amazon RDS podem estar em diferentes zonas de disponibilidade. Você deve configurar suas ACLs de rede para garantir que a comunicação entre as zonas de disponibilidade seja possível.

Um grupo de sub-rede de banco de dados existente pode ser atualizado para adicionar mais sub-redes para zonas de disponibilidade existentes ou para novas zonas de disponibilidade adicionadas após a criação da instância de banco de dados. A remoção de sub-redes de um grupo de sub-redes de banco de dados existente pode causar indisponibilidade para instâncias, caso elas estejam sendo executadas em uma AZ específica que é removida do grupo de sub-redes. Consulte o Guia do usuário do Amazon RDS para obter mais informações.

Para começar a utilizar o Amazon RDS, é necessário ter uma conta de desenvolvedor da AWS. Se você não tiver uma antes de se cadastrar para o Amazon RDS, você será solicitado a criar uma ao iniciar o processo de cadastramento. Uma conta de usuário principal é diferente de uma conta de desenvolvedor da AWS e é usada somente no contexto do Amazon RDS para controlar o acesso à(s) sua(s) instância(s) de banco de dados. A conta de usuário principal é uma conta de usuário de banco de dados nativa que você pode utilizar para se conectar à sua instância de banco de dados. 

É possível especificar o nome do usuário principal e a senha que deseja associar a cada instância de banco de dados ao criar a instância de banco de dados. Após criar sua instância de banco de dados, é possível conectar-se ao banco de dados utilizando as credencias de usuário principal. Consequentemente, você também pode desejar criar contas de usuário adicionais para restringir quem pode acessar sua Instância de banco de dados.

Para o MySQL, os privilégios padrão para o usuário principal incluem: criar, remover, referências, evento, alterar, excluir, indexar, inserir, selecionar, atualizar, criar tabelas temporárias, bloquear tabelas, disparar, criar visualização, exibir visualização, alterar rotina, criar rotina, executar, disparar, criar usuário, processar, exibir banco de dados, conceder opção.

Para o Oracle, a função “dba” é concedida ao usuário principal. O usuário principal herda a maioria dos privilégios associados com a função. Leia o Guia do usuário do Amazon RDS para ver a lista de privilégios restritos e as alternativas correspondentes para realizar tarefas administrativas que podem exigir esses privilégios.

Para o SQL Server, um usuário que criar um banco de dados receberá a função de “db_owner”. Leia o Guia do usuário do Amazon RDS para ver a lista de privilégios restritos e as alternativas correspondentes para realizar tarefas administrativas que podem exigir esses privilégios.

Não, tudo funciona da mesma maneira que com um banco de dados relacional que você mesmo gerencia.

Sim. Você deve ativar intencionalmente a capacidade de acessar o banco de dados pela internet configurando os Grupos de segurança. Você pode autorizar acesso somente para IPs, faixas de IP ou sub-redes específicos correspondentes a servidores em seu próprio datacenter.

Sim, essa opção é compatível com todos os mecanismos do Amazon RDS. O Amazon RDS gera um certificado SSL/TLS para cada instância de banco de dados. Após estabelecer uma conexão criptografada, os dados transferidos entre a instância de banco de dados e sua aplicação serão criptografados durante a transferência.

Apesar do SSL/TLS oferecer benefícios de segurança, tenha em mente que a criptografia SSL é uma operação intensiva computacionalmente que aumentará a latência de sua conexão com o banco de dados. O Amazon RDS oferece suporte ao SSL/TLS para criptografar a conexão entre a aplicação e a instância de banco de dados, e não deve ser usado para autenticar a própria instância de banco de dados.

Para obter mais detalhes sobre como estabelecer uma conexão criptografada com o Amazon RDS, consulte o Guia do usuário do MySQL, Guia do usuário do MariaDB, Guia do usuário do PostgreSQL ou o Guia do usuário do Oracle do Amazon RDS. Para saber mais sobre como o SSL/TLS funciona com esses mecanismos consulte diretamente as documentações do MySQL, do MariaDB, do MSDN SQL Server, do PostgreSQL ou da Oracle.

O Amazon RDS oferece suporte à criptografia de dados em repouso para todos os mecanismos de banco de dados usando chaves gerenciadas por você no AWS Key Management Service (KMS). Em uma instância de banco de dados em execução com a criptografia do Amazon RDS, os dados ociosos mantidos no armazenamento subjacente são criptografados, bem como os backups automáticos, as réplicas de leitura e os snapshots desses dados. A criptografia e a descriptografia são processadas de forma transparente. Para obter mais informações sobre o uso do KMS com o Amazon RDS, consulte o Guia do usuário do Amazon RDS.

Você também pode adicionar criptografia a uma instância ou cluster de banco de dados previamente não criptografado criando um DB snapshot, criando uma cópia desse snapshot e especificando uma chave de criptografia do KMS. Em seguida, você pode restaurar uma instância ou um cluster de banco de dados criptografado a partir do snapshot criptografado.

O Amazon RDS para Oracle e SQL Server oferecem suporte às tecnologias Transparent Data Encryption (TDE)desses mecanismos. Para obter mais informações, consulte o Guia do usuário do Amazon RDS para Oracle e SQL Server.

Você pode controlar as ações os usuários e grupos do AWS IAM podem executar nos recursos do Amazon RDS. Faça isso referenciando os recursos do Amazon RDS nas políticas do AWS IAM aplicadas a seus usuários e grupos. Os recursos do Amazon RDS que podem ser referenciados em uma política do IAM da AWS incluem instâncias de banco de dados, snapshots de banco de dados, réplicas de leitura, grupos de segurança de banco de dados, grupos de opções de banco de dados, grupos de parâmetros de banco de dados, assinaturas de eventos e grupos de sub-redes de banco de dados. 

Além disso, você pode marcar esses recursos para adicionar outros metadados aos seus recursos. Usando a marcação, você pode classificar seus recursos (por exemplo, instâncias de banco de dados de “Desenvolvimento”, instâncias de banco de dados de “Produção” e instâncias de banco de dados de “Teste”), bem como escrever políticas do AWS IAM que listam as permissões (por exemplo, ações) que podem ser realizadas nos recursos com as mesmas etiquetas. Para obter mais informações, consulte Marcar recursos do Amazon RDS.

Sim. O AWS CloudTrail é um serviço Web que registra as chamadas de API da AWS para a sua conta e envia os arquivos de log para você. O histórico de chamadas de APIs da AWS gerado pelo CloudTrail possibilita análises de segurança, rastreamento de alteração de recursos e auditoria de conformidade. 

Sim, todos os mecanismos de banco de dados do Amazon RDS são qualificados para HIPAA, portanto, você pode usá-los para criar aplicações compatíveis com a HIPAA e armazenar informações relacionadas à saúde, incluindo informações de saúde protegidas (PHI), mediante assinatura de um Business Associate Agreement (BAA - acordo de associado comercial) com a AWS.

Se você já tiver um BAA assinado, nenhuma ação será necessária para começar a usar esses serviços nas contas cobertas pelo BAA. Se você não tiver um BAA assinado com a AWS ou tiver qualquer dúvida sobre aplicativos em conformidade com a HIPAA na AWS, entre em contato com o gerente da sua conta.

Como padrão, o Amazon RDS escolhe parâmetros de configuração ideais para a sua instância de banco de dados, levando em conta a categoria e a capacidade de armazenamento da instância. No entanto, se você desejar alterá-los, use o Console de Gerenciamento da AWS, as APIs do Amazon RDS ou a Interface da Linha de Comando da AWS. Leve em consideração que a alteração dos parâmetros de configuração dos valores recomendados pode ter efeitos indesejados, que variam de uma queda de performance até falhas de sistema. A alteração só deve ser feita por usuários avançados que queiram assumir esses riscos.

Um parameter group de banco de dados age como um “contêiner” para valores de configuração de mecanismo que podem ser aplicados a uma ou mais instâncias de banco de dados. Se você criar uma instância de banco de dados sem especificar um parameter group de banco de dados, será utilizado um parameter group de banco de dados padrão. Esse grupo padrão contém padrões de mecanismos e padrões de sistema do Amazon RDS otimizados para a instância de banco de dados que você está executando.

Contudo, se você deseja executar sua instância de banco de dados com seus valores personalizados de configuração de mecanismo, basta criar um novo parameter group de banco de dados, modificar os parâmetros desejados e modificar a instância de banco de dados para utilizar o novo parameter group de banco de dados. Após serem associadas, todas as instâncias de banco de dados que utilizam um parameter group do banco de dados específico recebem todas as atualizações de parâmetro para aquele parameter group de banco de dados.

Para obter mais informações sobre como configurar grupos de parâmetros de banco de dados, leia o Guia do usuário do Amazon RDS.

Você pode usar o AWS Config para registrar continuamente as alterações nas configurações das instâncias de banco de dados do Amazon RDS, dos grupos de sub-redes de banco de dados, dos DB Snapshots, dos grupos de segurança de banco de dados e das assinaturas de eventos, além de receber notificações de alterações através do Amazon Simple Notification Service (SNS). Você também pode criar regras do AWS Config para avaliar se esses recursos do Amazon RDS têm as configurações desejadas.

Ao criar ou modificar a instância de banco de dados para que ela seja executada como uma implantação multi-AZ, o Amazon RDS provisiona e mantém automaticamente uma réplica síncrona “em espera” em uma zona de disponibilidade diferente. As atualizações de instância de banco de dados são replicadas simultaneamente por meio de zonas de disponibilidade para a espera, a fim de manter ambos em sincronia e proteger as últimas atualizações de banco de dados contra falhas de instância de banco de dados. 

Durante alguns tipos de manutenção programada, ou no caso de falha de instância de banco de dados ou falha de zona de disponibilidade, o Amazon RDS automaticamente fará o failover para a espera, para que você possa retomar gravações e leituras de banco de dados assim que a espera for promovida. Como o registro de nome para a instância de banco de dados permanece o mesmo, a aplicação pode retomar as operações de banco de dados sem precisar de intervenção administrativa manual. Com implantações Multi-AZ, a replicação é transparente. Você não interagirá diretamente com o modo standby e ele não poderá ser usado para ler tráfego. Mais informações sobre as implantações multi-AZ podem ser encontradas no Guia do usuário do Amazon RDS.

As zonas de disponibilidade são locais distintos em uma região que são projetados para serem isolados de falhas acarretadas por outras zonas de disponibilidade. Cada zona de disponibilidade opera em sua própria infraestrutura fisicamente distinta e independente e é projetada para ser altamente confiável. Pontos comuns de falhas, como geradores e equipamentos de refrigeração, não são compartilhados pelas zonas de disponibilidade. Além disso, eles são fisicamente separados, de tal forma que mesmo desastres extremamente incomuns, como incêndios, tornados ou enchentes, afetariam somente uma única zona de disponibilidade. As Zonas de disponibilidade dentro da mesma região beneficiam-se de conectividade de rede com baixa latência.

Ao executar uma instância de banco de dados como uma implantação Multi-AZ, o “principal” atende às gravações e leituras de banco de dados. Além disso, o Amazon RDS providencia e mantém um “em espera” em segundo plano, que é uma réplica atualizada da principal. O em espera é “promovido” em situações de failover. Após um failover, o em espera se torna o principal e aceita suas operações de banco de dados. Você não interage diretamente com o em espera (por exemplo, operações de leitura) em nenhum momento antes da promoção. Se você estiver interessado em escalar o tráfego de leitura além das restrições de capacidade de uma única instância de banco de dados, consulte as perguntas frequentes sobre réplicas de leitura.

Os principais benefícios de executar a instância de banco de dados como uma implantação Multi-AZ são a resiliência e a disponibilidade aprimoradas do banco de dados. A disponibilidade e tolerância a falhas mais abrangentes oferecidas por implantações Multi-AZ as tornam a melhor opção para ambientes de produção.
 

A execução da instância de banco de dados como uma implantação Multi-AZ protege os dados caso ocorra, inesperadamente, uma falha de componentes de instância de banco de dados ou uma perda de disponibilidade em uma zona de disponibilidade. Por exemplo, se um volume de armazenamento de seu principal falhar, o Amazon RDS automaticamente inicia um failover para o em espera, onde todas as atualizações de seu banco de dados estão intactas. Isso fornece uma durabilidade de dados adicional relativa às implantações padrão em um único AZ, em que uma operação de restauração feita por usuário seria necessária e atualizações feitas após o último momento restaurável (geralmente dentro dos últimos cinco minutos) não estariam disponíveis.

Você também se beneficiará da disponibilidade aprimorada do banco de dados ao executar sua instância de banco de dados como uma implantação Multi-AZ. Se ocorrer uma falha de zona de disponibilidade ou de instância de banco de dados, o impacto em sua disponibilidade estará limitado ao tempo que o failover automático leva para ser concluído. Os benefícios de disponibilidade do Multi-AZ também se estendem à manutenção planejada.

Com backups automatizados, por exemplo, a atividade de E/S não é mais suspensa no seu principal durante sua janela de manutenção preferencial, pois os backups são retirados da espera. No caso de aplicação de patches ou escalabilidade de classe de instância de banco de dados, essas operações ocorrem primeiro na espera, antes do failover automático. Como resultado, o impacto de disponibilidade é limitado ao tempo necessário para o failover automático ser concluído.

Outro benefício decorrente da execução da instância de banco de dados como uma implantação Multi-AZ é o failover de instância de banco de dados automático que não exige nenhuma administração. No contexto do Amazon RDS, isso significa que você não precisa monitorar eventos de instância de banco de dados e iniciar a recuperação manual da instância de banco de dados (por meio das APIs RestoreDBInstanceToPointInTime ou RestoreDBInstanceFromSnapshot) caso haja uma falha de zona de disponibilidade ou falha de instância de banco de dados.

É possível observar latências elevadas relacionadas a uma implantação padrão de instância de banco de dados em uma única zona de disponibilidade, resultantes da replicação de dados simultânea realizada em seu nome.

Não, um Multi-AZ em espera não pode executar solicitações de leitura. Implantações Multi-AZ são projetadas para fornecer disponibilidade e resiliência de banco de dados aprimoradas e não benefícios de escalabilidade de leitura. Sendo assim, o recurso utiliza replicação simultânea entre principal e em espera. Nossa implementação garante que o principal e o em espera estejam constantemente sincronizados, mas impede o uso do em espera para operações de leitura ou de gravação. Caso tenha interesse em uma solução de escalabilidade de leitura, consulte nossas Perguntas frequentes sobre réplicas de leitura.

Para criar uma implantação de instância de banco de dados Multi-AZ, basta clicar na opção “Sim” da seção “Implantação Multi-AZ” ao iniciar uma instância de banco de dados com o Console de Gerenciamento da AWS.

Como alternativa, se você estiver utilizando as APIs do Amazon RDS, poderá chamar a API CreateDBInstance e configurar o parâmetro “Multi-AZ” com o valor “true”. Para converter uma instância de banco de dados padrão (AZ único) para Multi-AZ, modifique a instância de banco de dados no Console de Gerenciamento da AWS ou utilize a API ModifyDBInstance e configure o parâmetro Multi-AZ como verdadeiro.

Para os mecanismos de banco de dados RDS para PostgreSQL, RDS para MySQL, RDS para MariaDB, RDS para SQL Server, RDS para Oracle e RDS para Db2, ao optar por converter a instância do Amazon RDS de Single-AZ para Multi-AZ, ocorre o seguinte:

• Um snapshot da instância principal é criado.
• Uma nova instância em espera é criada em uma zona de disponibilidade diferente da zona em que o snapshot está.
• A replicação síncrona é configurada entre as instâncias primária e em espera.

Dessa forma, não deve ocorrer tempo de inatividade quando uma instância é convertida de Single-AZ para Multi-AZ. No entanto, você poderá ver um aumento na latência enquanto os dados em espera são alcançados para corresponder à primária.

O Amazon RDS detecta e recupera automaticamente os cenários de falha mais comuns das implantações Multi-AZ para que você possa reiniciar as operações de banco de dados o mais rápido possível, sem intervenção administrativa. O Amazon RDS executa automaticamente um failover em qualquer uma das seguintes ocorrências:

• Perda de disponibilidade na Zona de disponibilidade principal
• Perda de conectividade de rede para principal
• Falha de unidade computacional na principal
• Falha de armazenamento na principal

Observação: quando operações como ações de escalabilidade de instâncias de banco de dados ou atualizações de sistema como a aplicação de patches no SO são iniciadas em implantações Multi-AZ, elas são aplicadas primeiro na espera antes de um failover automático para oferecer melhor disponibilidade. Como resultado, o impacto na disponibilidade será limitado ao tempo necessário para a conclusão do failover automático. Note que implantações Multi-AZ do Amazon RDS não executam failover automaticamente em caso de operações de banco de dados como consultas com execução demorada, bloqueios ou erros de corrupção de banco de dados.

Sim. O Amazon RDS emitirá um evento de instância de banco de dados para informá-lo que houve um failover. Clique na seção “Events” do console do Amazon RDS ou use a API DescribeEvents para retornar informações sobre eventos relacionados à instância de banco de dados. Você também poderá usar as notificações de evento do Amazon RDS para receber notificações quando ocorrerem eventos específicos de banco de dados.

O failover é automaticamente controlado pelo Amazon RDS para que você possa retomar operações de banco de dados o mais rápido possível e sem intervenção administrativa. Ao ocorrer um failover, o Amazon RDS troca o registro de nome canônico (CNAME) da instância de banco de dados para indicar a espera, que em troca é promovida e se torna o novo principal. Encorajamos você a seguir práticas recomendadas e implementar novas tentativas de conexão de banco de dados na camada de aplicativo.

Os failovers, definidos como o intervalo entre a detecção da falha no banco de dados principal e a retomada das transações no banco de dados de espera, em geral são concluídos em um a dois minutos. O tempo de failover também pode ser afetado pela necessidade ou não de grandes transações não confirmadas serem recuperadas; o uso de tipos de instância adequadamente grandes é recomendado com o Multi-AZ para a obtenção dos melhores resultados. A AWS também recomenda o uso de IOPS provisionadas com instâncias Multi-AZ para obtenção de alto desempenho, previsibilidade e taxa de transferência constante.

O Amazon RDS executará failover automaticamente e sem intervenção do usuário em diversas condições de falha. Além disso, o Amazon RDS oferece uma opção para iniciar um failover quando reiniciar sua instância. Você pode acessar este recurso por meio do Console de Gerenciamento da AWS ou ao usar a chamada API RebootDBInstance.

Com implantações Multi-AZ, basta definir o parâmetro “Multi-AZ” como verdadeiro. A criação da espera, da replicação simultânea e do failover é controlada automaticamente. Isso significa que não é possível selecionar a zona de disponibilidade em que a espera é implantada ou alterar o número de esperas disponíveis (o Amazon RDS provisiona uma espera dedicada por instância de banco de dados principal). A espera também não pode ser configurada para aceitar atividades de leitura do banco de dados. Saiba mais sobre configurações Multi-AZ.

Sim. A espera é automaticamente provisionada em uma zona de disponibilidade diferente da mesma região que a instância de banco de dados principal.

Sim, é possível visualizar o local da principal atual utilizando o Console de Gerenciamento da AWS ou a API DescribeDBInstances.

As zonas de disponibilidade são projetadas para fornecer conectividade de rede de baixa latência para outras zonas de disponibilidade na mesma região. Além disso, você tem a opção de criar seu aplicativo e outros recursos da AWS com redundância por meio de múltiplas zonas de disponibilidade para que seu aplicativo seja resistente no caso de uma falha de zona de disponibilidade. Implantações Multi-AZ abordam essa necessidade para a tier do banco de dados sem administração de sua parte.

A interação com a funcionalidade de backup automatizado e de DB snapshot é a mesma de uma implantação padrão Single-AZ ou Multi-AZ. Se você estiver executando uma implantação Multi-AZ, os backups automatizados e DB snapshots serão simplesmente executados na espera para evitar suspensão de E/S na principal. Note que você poderá experimentar uma maior latência de E/S (normalmente por alguns minutos) durante os backups de implantações Single-AZ e Multi-AZ.

O início de uma operação de restauração (restauração point-in-time ou de um DB snapshot) também funciona da mesma forma para implantações Multi-AZ e Single-AZ padrão. Novas implantações de instância de banco de dados podem ser criadas com as APIs RestoreDBInstanceFromSnapshot ou RestoreDBInstanceToPointInTime. Essas novas implantações de instância de banco de dados podem ser padrão ou Multi-AZ, independentemente do backup de origem ter sido iniciado em uma implantação padrão ou Multi-AZ.

Asréplicas de leitura facilitam o aproveitamento da funcionalidade de replicação integrada nos mecanismos com suporte para aumentar a escala horizontalmente de maneira elástica para além das restrições de capacidade de uma única instância de banco de dados para workloads de banco de dados com uso intensivo de leitura.

Você pode criar uma réplica de leitura com apenas alguns cliques no Console de Gerenciamento da AWS ou usando a API CreateDBInstanceReadReplica. Após a criação da réplica de leitura, atualizações de banco de dados na instância de banco de dados de origem serão replicadas utilizando uma replicação assíncrona nativa do mecanismo compatível. É possível criar múltiplas Réplicas de leitura para uma determinada Instância de Banco de Dados e distribuir o tráfego de leitura de seu aplicativo entre elas.

Como as réplicas de leitura usam a replicação incorporada dos mecanismos compatíveis, estão sujeitas às suas capacidades e limitações. Mais especificamente, as atualizações são aplicadas às réplicas de leitura depois que elas ocorrerem na instância de banco de dados de origem e o atraso da replicação pode variar significativamente. As réplicas de leitura podem ser associadas a implantações Multi-AZ para a obtenção de benefícios de escalabilidade de leitura, além da disponibilidade aprimorada de gravação de banco de dados e durabilidade de dados fornecida pelas implantações Multi-AZ.

Há inúmeros casos em que implantar uma ou mais réplicas de leitura para uma instância de banco de dados específica pode fazer sentido. Razões comuns para implementar uma réplica de leitura incluem:

• Expandir além da capacidade computacional ou de E/S de uma única instância de banco de dados para cargas de trabalho de leitura pesadas de banco de dados. Esse tráfego de leitura excessivo pode ser direcionado a uma ou mais réplicas de leitura.
• Atender ao tráfego de leitura enquanto a instância de banco de dados de origem está indisponível. Se sua instância de banco de dados de origem não consegue atender às solicitações de E/S (por exemplo, devido à suspensão de E/S para backups ou à manutenção programada), é possível direcionar tráfego de leitura para suas réplicas de leitura. Para esse caso de uso, lembre-se de que os dados na réplica de leitura podem estar “desatualizados”, pois a instância de banco de dados de origem não está disponível.
• Cenários de relatórios de negócios ou de data warehousing. Você pode desejar que as consultas de relatórios de negócios sejam executadas em uma réplica de leitura ao invés de em sua instância de banco de dados principal de produção.
• Você pode usar uma réplica de leitura para recuperação de desastres da instância de banco de dados de origem na mesma região da AWS ou em outra região.

Sim. Habilite backups automáticos na instância de banco de dados de origem antes de adicionar réplicas de leitura, definindo o período de retenção de backup como um valor diferente de 0. Os backups devem permanecer habilitados para que as réplicas de leitura funcionem.

Amazon Aurora: todos os clusters de banco de dados.

Amazon RDS para MySQL: todas as instâncias de banco de dados oferecem suporte à criação de réplicas de leitura. Os backups automáticos devem estar e permanecer habilitados na instância de banco de dados de origem para operações de réplica de leitura. Os backups automáticos na réplica têm suporte apenas para réplicas de leitura do Amazon RDS que executam MySQL 5.6 ou posteriores, portanto, não têm suporte para a versão 5.5.

Amazon RDS para PostgreSQL: instâncias de banco de dados com PostgreSQL versão 9.3.5 ou mais recentes oferecem suporte à criação de réplicas de leitura. As instâncias existentes com PostgreSQL anteriores à versão 9.3.5 precisam ser atualizadas para o PostgreSQL versão 9.3.5 para possibilitar o uso das réplicas de leitura do Amazon RDS.

Amazon RDS para MariaDB: todas as instâncias de banco de dados oferecem suporte à criação de réplicas de leitura. Os backups automáticos devem estar e permanecer habilitados na instância de banco de dados de origem para operações de réplica de leitura.

Amazon RDS para Oracle: compatível com o Oracle versão 12.1.0.2.v12 ou superiores e com todas as versões 12.2 que usam o modelo Bring Your Own License com o Oracle Database Enterprise Edition e tem licença para a opção Active Data Guard.

Amazon RDS para SQL Server: as réplicas de leitura têm suporte no Enterprise Edition na configuração Multi-AZ quando a tecnologia de replicação subjacente está usando os grupos de disponibilidade Always On para SQL Server versões 2016 e 2017.

Você pode criar uma réplica de leitura em minutos usando a API CreateDBInstanceReadReplica padrão ou com apenas alguns cliques no Console de Gerenciamento da AWS. Ao criar uma réplica de leitura, você pode identificá-la como uma réplica de leitura especificando um SourceDBInstanceIdentifier. O SourceDBInstanceIdentifier é o DB Instance Identifier da instância de banco de dados de “origem” a partir da qual você deseja fazer a replicação. Da mesma forma que com uma instância de banco de dados padrão, também é possível especificar a zona de disponibilidade, a classe de instância de banco de dados e a janela de manutenção preferida. A versão do mecanismo (por exemplo, PostgreSQL 9.3.5) e a alocação de armazenamento de uma réplica de leitura são herdadas da instância de banco de dados de origem. 

Ao iniciar a criação de uma réplica de leitura, o Amazon RDS faz um snapshot de sua instância de banco de dados de origem e inicia a replicação. Como resultado, ocorrerá uma breve suspensão de E/S de sua instância de banco de dados de origem à medida que ocorrer o snapshot. Essa suspensão de E/S geralmente dura cerca de um minuto e pode ser evitada se a instância de banco de dados de origem for uma implantação Multi-AZ (no caso de implantações Multi-AZ, snapshots são realizados a partir da espera).

No momento, o Amazon RDS também está trabalhando em uma otimização (a ser lançada em breve) para que, ao criar várias réplicas de leitura durante uma janela de 30 minutos, todas elas utilizem o mesmo snapshot de origem para minimizar o impacto de E/S (replicação "para recuperar o atraso" pois cada réplica de leitura iniciará após a criação).

É possível se conectar a uma réplica de leitura da mesma maneira que a uma instância de banco de dados padrão utilizando a API DescribeDBInstance ou o Console de Gerenciamento da AWS para recuperar os endpoints para suas réplicas de leitura. Se você tem várias réplicas de leitura, seu aplicativo terá de determinar como o tráfego de leitura será distribuído entre elas.

O Amazon RDS para MySQL, MariaDB e PostgreSQL permite criar até 15 réplicas de leitura para determinada instância de banco de dados de origem. O Amazon RDS para Oracle e SQL Server permite criar até cinco réplicas de leitura para determinada instância de banco de dados de origem.

Sim, o Amazon RDS (exceto o RDS for SQL Server) agora oferece suporte para réplicas de leitura entre regiões. A quantidade de tempo entre o momento em que os dados são gravados na instância de banco de dados de origem e quando ficam disponíveis na réplica de leitura dependerá da latência da rede entre as duas regiões.

Não. As réplicas de leitura no Amazon RDS for MySQL, MariaDB, PostgreSQL, Oracle e SQL Server são implementadas usando a replicação assíncrona nativa desses mecanismos. O Amazon Aurora usa um mecanismo de replicação diferente, mas ainda assim assíncrono.

Se você deseja utilizar a replicação para aumentar a disponibilidade de gravação de banco de dados e proteger atualizações de banco de dados recentes contra diversas situações de falha, recomendamos que execute sua instância de banco de dados como uma implantação Multi-AZ. Com as réplicas de leitura do Amazon RDS, que usam a replicação assíncrona nativa dos mecanismos compatíveis, as gravações de banco de dados ocorrem em uma réplica de leitura após serem realizadas na instância de banco de dados de origem. Esse “atraso” de replicação pode variar consideravelmente. 

Em contraste, a replicação utilizada pelas implantações Multi-AZ são simultâneas, de forma que todas as gravações de banco de dados são concomitantes na principal e na espera. Isso protege suas atualizações de banco de dados mais recentes, pois elas devem estar disponíveis na espera caso um failover seja necessário. 

Além disso, com implantações Multi-AZ, a replicação é gerenciada. O Amazon RDS monitora automaticamente condições de falha de instâncias de banco de dados ou de zonas de disponibilidade e inicia o failover automático para a espera (ou para um réplica de leitura, no caso do Amazon Aurora) se uma interrupção ocorrer.

Sim. Já que as instâncias de banco de dados Multi-AZ atendem a uma necessidade diferente de réplicas de leitura, faz sentido utilizar as duas em conjunto para implantações de produção e associar uma réplica de leitura a uma implantação Multi-AZ de instância de banco de dados. A instância de banco de dados Multi-AZ de “origem” fornece disponibilidade de gravação e resiliência de dados aprimoradas, e a réplica de leitura associada pode melhorar a escalabilidade do tráfego de leitura.

Sim. O Amazon RDS for MySQL, MariaDB, PostgreSQL e Oracle permite habilitar a configuração Multi-AZ em réplicas de leitura para oferecer suporte à recuperação de desastres e minimizar o tempo de inatividade das atualizações do mecanismo.

Caso ocorra um failover Multi-AZ, qualquer réplica de leitura associada e disponível automaticamente retomarão a replicação após a conclusão do failover (adquirindo atualizações da primaria recém-promovida).

Amazon Aurora, Amazon RDS para MySQL e MariaDB: você pode criar três níveis de réplicas de leitura. Uma réplica de leitura de segundo nível de uma réplica de leitura de primeiro nível existente e uma réplica de terceiro nível de réplicas de leitura de segundo nível. Ao criar uma réplica de leitura de segundo e terceiro níveis, você pode mover parte da carga de replicação da instância de banco de dados principal para diferentes níveis de réplica de leitura com base nas necessidades de sua aplicação.

Observe que uma réplica de leitura de segunda camada pode apresentar um atraso maior em relação à primária devido à latência de replicação adicional introduzida conforme as transações são replicadas da instância primária para a réplica de primeira camada e depois para a réplica de segunda camada. De maneira semelhante, a réplica de terceiro nível pode ficar para trás da réplica de leitura de segundo nível.

Amazon RDS para Oracle e Amazon RDS para SQL Server: no momento, não há suporte para réplicas de leitura de réplicas de leitura.

Réplicas de leitura destinam-se a auxiliar o tráfego de leitura. Contudo, pode haver casos de uso em que usuários avançados desejem completar instruções SQL de Linguagem de definição de dados (DDL) contra uma réplica de leitura. Os exemplos podem incluir adicionar um índice de banco de dados a uma réplica de leitura, que é utilizada para relatórios de negócios, sem adicionar o mesmo índice à instância de banco de dados de origem correspondente.

O Amazon RDS for MySQL pode ser configurado para permitir a execução de instruções de DDL SQL em uma réplica de leitura. Se você deseja habilitar operações além de leituras para uma determinada réplica de leitura, modifique o parameter group de banco de dados ativo para a réplica de leitura, configurando o parâmetro “read_only” para “0”.

No momento, o Amazon RDS para PostgreSQL não oferece suporte à execução de instruções de DDL SQL em uma réplica de leitura.

Sim. Consulte o Guia do usuário do Amazon RDS para obter mais detalhes.

As atualizações para uma instância de banco de dados de origem serão automaticamente replicadas a qualquer réplica de leitura associada. No entanto, com a tecnologia de replicação assíncrona dos mecanismos compatíveis, uma réplica de leitura pode ficar defasada em relação à instância de banco de dados de origem por vários motivos. Os principais motivos incluem:

• O volume de E/S de gravação para a instância de banco de dados de origem excede a taxa à qual pode ser aplicada a réplica de leitura (esse problema tem mais probabilidade de surgir se a capacidade computacional de uma réplica de leitura é menor do que a instância de banco de dados de origem)
• As transações complexas ou de longa duração para a instância de banco de dados de origem atrasam a replicação para a réplica de leitura
• Partições de rede ou latência entre a instância de banco de dados de origem e uma réplica de leitura

As réplicas de leitura estão sujeitas às capacidades e limitações da replicação nativa dos mecanismos compatíveis. Se você estiver utilizando réplicas de leitura, deverá estar ciente do potencial atraso entre uma réplica de leitura e a instância de banco de dados de origem, ou “inconsistência”.

Você pode utilizar a API DescribeDBInstances padrão para retornar uma lista de todas as instâncias de banco de dados implantadas (inclusive réplicas de leitura) ou apenas clicar na guia “Instances” (Instâncias) do console do Amazon RDS.

O Amazon RDS oferece visibilidade sobre o tamanho da defasagem da réplica de leitura em relação à instância de banco de dados de origem. O número de segundos de defasagem da réplica de leitura em relação ao principal é publicado como uma métrica do Amazon CloudWatch (“Replica Lag” – atraso da réplica), disponível no Console de Gerenciamento da AWS ou por meio das APIs do Amazon CloudWatch.

No Amazon RDS para MySQL, a origem dessas informações é a mesma que é exibida pela execução do comando MySQL padrão “Show Replica Status” (Exibir status do secundário) na réplica de leitura. No Amazon RDS for PostgreSQL, você pode usar a visualização pg_stat_replication na instância de banco de dados de origem para explorar as métricas de replicação.

O Amazon RDS monitora o status de replicação das réplicas de leitura e atualiza o campo Replication State do Console de Gerenciamento da AWS com o valor “Error” se a replicação for interrompida por qualquer motivo (por exemplo, a tentativa de executar consultas DML na réplica que está em conflito com as atualizações feitas nas instâncias principais do banco de dados pode causar um erro de replicação). É possível examinar os detalhes do erro associado gerado pelo mecanismo do MySQL visualizando o campo Replication Error (Erro de réplica) e executar as ações adequadas para recuperação. Saiba mais sobre como solucionar problemas de replicação na seção de solução de problemas de uma réplica de leitura do Guia do usuário do Amazon RDS para MySQL ou PostgreSQL. 

Se o erro de replicação é corrigido, o campo Replication State muda para Replicating.

Para uma replicação ser realizada com êxito, recomendamos que as réplicas de leitura tenham os mesmos ou mais recursos de computação e de armazenamento que suas respectivas instâncias de banco de dados de origem. Caso contrário, o atraso de replicação provavelmente aumentará ou sua réplica de leitura poderá ficar sem espaço para armazenar atualizações replicadas.

Exclua uma réplica de leitura com apenas alguns cliques no Console de Gerenciamento da AWS ou passando seu identificador de instância de banco de dados para a API DeleteDBInstance. 

Uma réplica de leitura do Amazon Aurora permanecerá ativa e continuará a aceitar tráfego de leitura mesmo depois que a sua instância de banco de dados de origem correspondente tiver sido excluída. Uma das réplicas de leitura no cluster será promovida automaticamente como a nova principal e começará a aceitar o tráfego.

Uma réplica de leitura do Amazon RDS for MySQL ou MariaDB permanecerá ativa e continuará a aceitar tráfego de leitura mesmo após sua instância de banco de dados de origem correspondente ter sido excluída. Se, além da instância de banco de dados de origem, você deseja excluir a réplica de leitura, é necessário fazê-lo explicitamente usando a API DeleteDBInstance ou o Console de Gerenciamento da AWS.

Se você excluir uma instância de banco de dados do Amazon RDS for PostgreSQL que tem réplicas de leitura, todas as réplicas de leitura serão promovidas para instâncias de banco de dados autônomas e poderão aceitar tráfego de leitura e gravação. As instâncias de banco de dados promovidas operarão de forma independente entre si. Se, além da instância de banco de dados de origem, você deseja excluir essas instâncias de banco de dados, deve fazê-lo explicitamente usando a API DeleteDBInstance ou o AWS Management Console.

Uma réplica de leitura é cobrada como uma instância de banco de dados padrão e com as mesmas taxas. Assim como uma Instância de banco de dados padrão, a taxa por "hora de Instância de banco de dados" para uma réplica de leitura é determinada pela classe de instância de banco de dados da réplica de leitura – acesse a página de preços para obter preços atualizados. Você não será cobrado pela transferência de dados que ocorrer na replicação de dados entre sua instância de banco de dados de origem e sua réplica de leitura dentro da mesma região da AWS.

A cobrança por uma réplica de leitura será iniciada assim que a réplica for criada com êxito (quando o status for listado como “ativo”). A réplica de leitura continuará sendo cobrada pela hora de Instância de banco de dados do Amazon RDS padrão, até que você acione um comando para excluí-la.

O monitoramento avançado para o Amazon RDS oferece visibilidade aprofundada da integridade de suas instâncias do Amazon RDS. Basta ativar a opção “Monitoramento avançado” para a instância de banco de dados do Amazon RDS e definir uma granularidade. O monitoramento avançado coletará métricas vitais do sistema operacional e informações de processo na granularidade definida.

Para obter um nível ainda mais profundo de diagnóstico e visualização da carga do banco de dados, e um período de retenção de dados mais longo, você pode experimentar os Insights de Performance.

O Enhanced Monitoring captura métricas no nível do sistema da sua instância do Amazon RDS, como CPU, memória, sistema de arquivos e E/S de disco, entre outras. A lista completa de métricas pode ser encontrada na documentação.

O Enhanced Monitoring é compatível com todos os mecanismos de banco de dados do Amazon RDS.

O Enhanced Monitoring é compatível com todos os tipos de instância, exceto t1.micro e m1.small. O software usa uma pequena quantidade de CPU, memória e E/S. Para o monitoramento de uso geral, recomendamos ativar granularidades mais altas para instâncias de tamanho médio ou grande. Para instâncias de banco de dados que não são de produção, a configuração padrão do Enhanced Monitoring é “off”, e você tem a opção de deixá-lo desabilitado ou modificar a granularidade quando ele estiver ativado.

Você pode ver todas as métricas do sistema e informações de processos das suas instâncias de banco de dados do Amazon RDS em um formato gráfico no console. Você pode gerenciar quais métricas deseja monitorar para cada instância e personalizar o painel de acordo com seus requisitos.

Não. Você pode definir diferentes granularidades para cada instância de banco de dados na sua conta do Amazon RDS. Também é possível escolher as instâncias nas quais você deseja habilitar o Enhanced Monitoring, bem como modificar a granularidade de qualquer instância sempre que quiser.

Você pode ver os valores de performance de todas as métricas de até 1 hora atrás, com granularidade de até 1 segundo, dependendo das suas configurações.

As métricas do Amazon RDS Enhanced Monitoring são entregues na sua conta do CloudWatch Logs. Você pode criar filtros de métricas no CloudWatch a partir do CloudWatch Logs e exibir os gráficos no painel do CloudWatch. Para obter mais detalhes, acesse a página do Amazon CloudWatch.

Você deve usar o CloudWatch se desejar ver dados históricos além dos que estiverem disponíveis no painel do console do Amazon RDS. Você pode monitorar suas instâncias do Amazon RDS no CloudWatch para diagnosticar a saúde de toda a sua pilha da AWS em um único local. Atualmente, o CloudWatch aceita granularidades de até 1 minuto e a média dos valores será calculada para granularidades inferiores a essa.

Sim. Você pode criar um alarme no CloudWatch que envia uma notificação quando o alarme muda de estado. O alarme monitorará uma única métrica ao longo de um período que você especificar e realizará uma ou mais ações com base no valor da métrica relativa ao limite especificado por vários períodos. Para obter mais detalhes sobre os alarmes do CloudWatch, consulte o Guia do desenvolvedor do Amazon CloudWatch.

O Enhanced Monitoring para Amazon RDS fornece um conjunto de métricas formadas como carga JSON que são entregues na sua conta do CloudWatch Logs. As cargas úteis JSON são entregues na última granularidade configurada para a instância do Amazon RDS.

Há duas maneiras de você consumir as métricas por meio de um painel ou uma aplicação de terceiros. As ferramentas de monitoramento podem usar Assinaturas do CloudWatch Logs para configurar um feed praticamente em tempo real para as métricas. Alternativamente, você pode usar filtros no CloudWatch Logs para enviar as métricas para o CloudWatch e integrar sua aplicação com o CloudWatch. Consulte a Documentação do Amazon CloudWatch para obter mais detalhes.

Como o Enhanced Monitoring entrega cargas úteis JSON em um log na sua conta do CloudWatch Logs, você poderá controlar seu período de retenção assim como qualquer outro fluxo do CloudWatch Logs. O período de retenção padrão configurado para o Enhanced Monitoring no CloudWatch Logs é de 30 dias. Para obter detalhes sobre como alterar as configurações de retenção, consulte o Guia do desenvolvedor do Amazon CloudWatch.

Como as métricas são ingeridas no CloudWatch Logs, suas cobranças serão baseadas nas taxas de transferência e armazenamento de dados do CloudWatch Logs depois que você exceder o nível gratuito do CloudWatch Logs. Detalhes dos preços podem ser encontrados aqui. A quantidade de informações transferida para uma instância do Amazon RDS é diretamente proporcional à granularidade definida para o recurso Enhanced Monitoring. Os administradores podem definir diferentes granularidades para diferentes instâncias em suas contas para gerenciar os custos.

O volume aproximado de dados ingeridos no CloudWatch Logs pelo Enhanced Monitoring para uma instância é mostrado abaixo:

O Amazon RDS Proxy é um atributo de proxy de banco de dados totalmente gerenciado e altamente disponível para o Amazon RDS. O RDS Proxy torna os aplicativos mais escaláveis, mais resistentes a falhas do banco de dados e mais seguros.

O Amazon RDS Proxy é um recurso de proxy de banco de dados totalmente gerenciado, altamente disponível e fácil de usar do Amazon RDS que permite que suas aplicações: 1) melhorem a escalabilidade ao agrupar e compartilhar conexões de banco de dados; 2) melhorem a disponibilidade ao reduzir o tempo de failover do banco de dados em até 66% e preservar as conexões das aplicações durante os failovers; e 3) melhorem a segurança ao aplicar opcionalmente a autenticação do AWS IAM aos bancos de dados e armazenar as credenciais com segurança no AWS Secrets Manager.

Dependendo da sua workload, o Amazon RDS Proxy pode adicionar uma média de 5 milissegundos de latência de rede ao tempo de resposta da consulta ou transação. Se a sua aplicação não puder tolerar 5 milissegundos de latência ou não precisar do gerenciamento de conexões e de outros recursos habilitados pelo RDS Proxy, convém que a aplicação se conecte diretamente ao endpoint do banco de dados.

O Amazon RDS Proxy transforma sua abordagem na criação de aplicações modernas com tecnologia sem servidor que aproveitam a capacidade e a simplicidade dos bancos de dados relacionais. Primeiro, o RDS Proxy permite que aplicações com tecnologia sem servidor sejam escaladas com eficiência, agrupando e reutilizando conexões de banco de dados. Segundo, com o RDS Proxy, você não precisa mais manipular credenciais de banco de dados no seu código Lambda. Você pode usar a função de execução do IAM associada à sua função do Lambda para autenticar o RDS Proxy e seu banco de dados. Terceiro, você não precisa gerenciar nenhuma nova infraestrutura ou código para utilizar todo o potencial de aplicativos sem servidor apoiados por bancos de dados relacionais. O RDS Proxy é totalmente gerenciado e dimensiona sua capacidade automaticamente com base nas demandas de sua aplicação.

O RDS Proxy está disponível para Amazon Aurora (compatível com MySQL), Amazon Aurora (compatível com PostgreSQL), Amazon RDS para MariaDB, Amazon RDS para MySQL, Amazon RDS para PostgreSQL e Amazon RDS para SQL Server. Para ver uma lista das versões compatíveis do mecanismo, consulte o Guia do usuário do Amazon Aurora ou o Guia do usuário do Amazon RDS.

Você habilita o Amazon RDS Proxy para seu banco de dados do Amazon RDS com apenas alguns cliques no console do Amazon RDS. Ao habilitar o RDS Proxy, você especifica a VPC e as sub-redes das quais deseja acessar o RDS Proxy. Como usuário do Lambda, você pode habilitar o Amazon RDS Proxy para o banco de dados do Amazon RDS e configurar uma função do Lambda para acessá-lo com apenas alguns cliques no console do Lambda.

Sim. Você pode usar as APIs do Amazon RDS Proxy para criar um proxy e, em seguida, definir grupos de destino para associar o proxy a instâncias ou clusters específicos do bancos de dados. Por exemplo:

aws rds create-db-proxy 
        --db-proxy-name '…' 
        --engine-family <mysql|postgresql>       
        --auth [{}, {}] 
        --role-arn '…'
        --subnet-ids {}
        --require-tls <true|false>
        --tags {}
aws rds register-db-proxy-targets 
        --target-group-name '…'
        --db-cluster-identifier  '…'
        --db-instance-identifier '…'

Com o Trusted Language Extensions (TLE) for PostgreSQL, os desenvolvedores podem criar extensões de alta performance para o PostgreSQL e executá-las com segurança no Amazon Aurora e no Amazon RDS. Ao fazer isso, a TLE melhora o seu tempo de introdução no mercado e elimina a carga imposta aos administradores de banco de dados para certificar códigos personalizados e de terceiros para uso em workloads de banco de dados de produção. Você pode prosseguir assim que decidir que uma extensão atende às suas necessidades. Com a TLE, os provedores de software independente (ISVs) pode fornecer novas extensões do PostgreSQL para clientes que usam o Aurora ou o Amazon RDS.

As extensões do PostgreSQL são executadas no mesmo espaço do processo para obter alta performance. No entanto, as extensões podem conter defeitos no software e causar uma pane no banco de dados.

O TLE para PostgreSQL oferece várias camadas de proteção para mitigar esse risco. A TLE é projetada para limitar o acesso aos recursos do sistema. O perfil rds_superuser pode determinar quem tem permissão para instalar extensões específicas. No entanto, essas alterações só podem ser feitas por meio da API da TLE. A TLE é projetada para limitar o impacto de um defeito na extensão a uma única conexão ao banco de dados. Além dessas medidas de proteção, a TLE é projetada para fornecer controle online e granular aos DBAs no perfil rds-superuser sobre quem pode instalar extensões e eles podem criar um modelo de permissão para executá-las.

Apenas usuários com privilégios suficientes serão capazes de executar e criar usando o comando “CREATE EXTENSION” em uma extensão TLE. Os DBAs também podem criar uma lista de “PostgreSQL hooks” permitidos que são necessários para extensões mais sofisticadas que modificam o comportamento interno do banco de dados e geralmente requerem privilégios elevados.

A TLE para PostgreSQL está disponível para o Amazon Aurora, edição compatível com PostgreSQL e Amazon RDS no PostgreSQL nas versões 14.5 e posteriores. A TLE é implementada como uma extensão do PostgreSQL e você pode ativá-la com a função rds_superuser da mesma forma que as outras extensões compatíveis com o Aurora e o Amazon RDS.

Você pode executar a TLE para PostgreSQL no PostgreSQL 14.5 ou posterior no Amazon Aurora e no Amazon RDS.  

O TLE para PostgreSQL está atualmente disponível em todas as regiões da AWS (exceto Regiões da AWS na China) e na AWS GovCloud.

A TLE para PostgreSQL está disponível para clientes do Aurora e do Amazon RDS sem custo adicional.

O Aurora e o Amazon RDS oferecem compatibilidade para uma lista selecionada de 85 extensões para PostgreSQL. A AWS gerencia os riscos de segurança para cada uma dessas extensões no âmbito do Modelo de Responsabilidade Compartilhada da AWS. A extensão que implementa o TLE para PostgreSQL está incluída nessa lista. As extensões que você escreve ou obtém de terceiros e instala em TLE são consideradas como parte do código da sua aplicação. Você é responsável pela segurança das suas aplicações que usam extensões TLE.

Você pode criar funções de desenvolvedor, como compressão de bitmap e privacidade diferencial (como consultas estatísticas com acesso público que protegem a privacidade de indivíduos).

No momento, o TLE para PostgreSQL é compatível com JavaScript, PL/pgSQL, Perl e SQL.

Depois que a função rds_superuser ativar a TLE para PostgreSQL, você pode implantar extensões TLE usando o comando SQL CREATE EXTENSION a partir de qualquer cliente PostgreSQL, como o psql, por exemplo. É semelhante à forma como você cria uma função definida pelo usuário em uma linguagem procedural como PL/pgSQL ou PL/Perl. Você pode controlar quais usuários tem permissão para implantar extensões TLE e usar extensões específicas.

O TLE para PostgreSQL acessa seu banco de dados PostgreSQL exclusivamente por meio da API TLE. As linguagens compatíveis com TLE incluem todas as funções da interface de programação do servidor (SPI) do PostgreSQL e PostgreSQL hooks, incluindo o de verificação de senha.

Saiba mais sobre o projeto do TLE para PostgreSQL na página oficial do TLE no GitHub.

As implantações azuis/verdes do Amazon RDS estão disponíveis no Amazon Aurora, edição compatível com MySQL, Amazon Aurora, edição compatível com PostgreSQL, Amazon RDS para MySQL, Amazon RDS para MariaDB e Amazon RDS para PostgreSQL. 

As implantações azuis/verdes do Amazon RDS estão disponíveis no Amazon Aurora edição compatível com MySQL, versões 5.6 e posterior, RDS para MySQL, versões 5.7 e posterior e RDS para MariaDB, versões 10.2 e posterior. As implantações azul/verde também são compatíveis com a edição compatível com PostgreSQL do Amazon Aurora e com o Amazon RDS para PostgreSQL nas versões 11.21 e superiores, 12.16 e superiores, 13.12 e superiores, 14.9 e superiores e 15.4 e superiores. Saiba mais sobre as versões disponíveis na documentação do Amazon Aurora e Amazon RDS. 

As implantações azuis/verdes do Amazon RDS estão disponíveis em todas as regiões da AWS aplicáveis e nas regiões AWS GovCloud.

As implantações azuis/verdes do Amazon RDS permitem que você faça alterações mais seguras, simples e rápidas no banco de dados. As implantações azuis/verdes são ideais para casos de uso como atualizações do mecanismo de banco de dados de versões principais ou secundárias, atualizações do sistema operacional, alterações de esquema em ambientes verdes que não interrompem a replicação lógica, como adicionar uma nova coluna no final de uma tabela ou alterações na configuração dos parâmetros do banco de dados. Você pode usar implantações azuis/verdes para fazer várias atualizações de banco de dados ao mesmo tempo usando uma única transição. Isso permite ficar em dia sobre os patches de segurança, melhorar a performance do banco de dados e acessar novos atributos do banco de dados com um tempo de inatividade curto e previsível.

Você pagará o mesmo preço se executar suas workloads em instâncias verdes ou azuis. O custo da execução em instâncias verdes e azuis inclui o nosso preço padrão atual para instâncias db, o custo de armazenamento, o custo de leitura/gravação de E/S e todos os atributos habilitados, como o custo de backups e Insights de Performance do Amazon RDS. Efetivamente, você paga aproximadamente o dobro do custo de execução de workloads em uma instância de banco de dados pela vida útil de uma implantação azul/verde.

Por exemplo: você tem um banco de dados RDS para MySQL 5.7 em execução em duas instâncias r5.2xlarge, um banco de dados primário e uma réplica de leitura, na região da AWS us-east-1 com uma configuração Multi-AZ (MAZ). Cada uma das instâncias r5.2xlarge está configurada para 20 GiB de Amazon Elastic Block Storage (EBS) de uso geral. Você cria um clone da topologia da instância azul usando implantações azuis/verdes do Amazon RDS, executa-a durante 15 dias (360 horas) e depois exclui a instância azul depois de uma alternância bem-sucedida. As instâncias azuis custam USD 1.387 por 15 dias a uma taxa sob demanda de USD 1,926 por hora (custo da instância + EBS). O custo total de uso de implantações azuis/verdes durante esses 15 dias é de USD 2.774, o que é aproximadamente o dobro da execução em instâncias azuis nesse período.

As implantações azul/verde do Amazon RDS permitem que você faça alterações de banco de dados mais seguras, simples e rápidas, como atualizações de versões principais ou secundárias, alterações de esquema, escalabilidade de instâncias, alterações de parâmetros de mecanismo e atualizações de manutenção.

Em implantações azuis/verdes do Amazon RDS, o ambiente azul é o seu ambiente de produção atual. O ambiente verde é seu ambiente de preparação que se tornará seu novo ambiente de produção após a transição.

Quando as implantações azuis/verdes do Amazon RDS iniciam uma transição, a gravação é bloqueada em ambos os ambientes, verde e azul, até que a transição seja concluída. Durante a transição, o ambiente de preparação, ou ambiente verde, é atualizado com o sistema de produção, garantindo que os dados estão consistentes entre os ambientes de produção e preparação. Assim que os ambientes de produção e preparação estiverem em total sincronia, as implantações azuis/verdes promoverão o ambiente de preparação como o ambiente de produção, redirecionando o tráfego para o ambiente de produção recém-promovido. As implantações azuis/verdes são projetadas para habilitar a gravação no ambiente verde após a conclusão da transição, garantindo que não houve perda de dados durante o processo.

Se seu ambiente azul for uma réplica lógica autogerenciada ou um assinante, bloquearemos a transição. Recomendamos que você primeiro interrompa a replicação para o ambiente azul, continue com a transição e, em seguida, retome a replicação. Por outro lado, se o seu ambiente azul for uma fonte para uma réplica lógica autogerenciada ou publicador, você poderá continuar a fazer a transição. No entanto, você precisará atualizar a réplica autogerenciada para replicá-la do ambiente verde após a transição.

As implantações azuis/verdes do Amazon RDS não excluem o seu ambiente de produção antigo. Se for necessário, você poderá acessá-lo para validações adicionais e testes de performance/regressão. Se você não precisar mais do seu ambiente de produção antigo, você poderá excluí-lo. Instâncias de produção antigas serão cobradas de acordo com a taxa padrão até que sejam excluídas.

As barreiras de proteção da alternância das implantações azuis/verdes do Amazon RDS bloqueiam a gravação nos seus ambientes azul e verde até que o ambiente verde esteja atualizado antes de concluir a troca. As implantações azuis/verdes também realizam verificações de integridade do principal e das réplicas nos seus ambientes azul e verde. Elas também realizam verificações de integridade da replicação, por exemplo, para ver se a replicação foi interrompida ou se há erros. Elas detectam transações de longa duração nos seus ambientes azul e verde. Você pode especificar um tempo de inatividade máximo tolerável de, no mínimo de 30 segundos, e se você tiver uma transação que exceda esse tempo, a transição será interrompida.

Não, as implantações azuis/verdes do Amazon RDS não são compatíveis com bancos de dados globais, Amazon RDS Proxy, réplicas de leitura em regiões diferentes ou réplicas de leitura em cascata.

Não, no momento, você não pode usar implantações azuis/verdes do Amazon RDS para reverter alterações.

O MySQL protege os usuários contra perda de dados gravando dados em páginas de 16KiB em memória duas vezes para armazenamento durável, primeiro no buffer de dupla gravação (“doublewrite buffer”) e depois no armazenamento de tabela. As Gravações otimizadas pelo Amazon RDS gravam suas páginas de dados de 16KiB diretamente nos seus arquivos de dados de forma confiável e durável em uma única etapa usando o atributo Prevenção de gravação interrompida do AWS Nitro System.

As Gravações otimizadas pelo Amazon RDS estão disponíveis na versão principal MySQL 8.0.30 e posterior do MySQL.

O Amazon RDS Optimized Writes está disponível nas instâncias db.r6i e db.r5b. Está disponível em todas as regiões em que essas instâncias estão disponíveis, exceto nas regiões da AWS da China.

Não. O Amazon Aurora edição compatível com MySQL já evita usar o “buffer de dupla gravação.” Em vez disso, o Amazon Aurora replica os dados de seis formas em três zonas de disponibilidade (AZs) e usa uma abordagem baseada em quorum para gravar dados de maneira durável e lê-los corretamente depois.

No momento, esta versão inicial não permite habilitar Gravações otimizadas pelo Amazon RDS em suas instâncias de bancos de dados existentes, mesmo que a classe da instância seja compatível com Gravações otimizadas.

As Gravações otimizadas pelo Amazon RDS estão disponíveis ao RDS para clientes do MySQL sem custo adicional.

Workloads que usam objetos temporários no MySQL e MariaDB para processamento de consultas se beneficiam do Amazon RDS Optimized Reads. O Optimized Reads posiciona objetos temporários no armazenamento da instância baseada em NVMe em vez de no volume Amazon Elastic Block Store. Isso ajuda a acelerar o processamento de consultas complexas em até duas vezes.

As Leituras otimizadas pelo Amazon RDS estão disponíveis no RDS para MySQL nas versões MySQL 8.0.28 e superiores e no RDS para MariaDB nas versões MariaDB 10.4.25, 10.5.16, 10.6.7 e superiores.

As Leituras otimizadas pelo Amazon RDS estão disponíveis em todas as regiões onde as instâncias db.r5d, db.m5d, db.r6gd, db.m6gd, X2idn, e X2iedn estiverem disponíveis. Para obter mais informações, consulte a documentação de classes de instâncias de bancos de dados do Amazon RDS.

Os clientes devem usar as Leituras otimizadas pelo Amazon RDS quando tiverem workloads que exigem consultas complexas; análises em geral; ou que requerem agrupamentos, classificações, agregações de hash, uniões de carga elevada e expressões de tabela comuns (CTEs). Esses casos de uso resultam na criação de tabelas temporárias, permitindo que as Leituras otimizadas agilizem o processamento de consulta da sua workload.

Sim, os clientes podem converter seus bancos de dados Amazon RDS para usar as Leituras otimizadas pelo Amazon RDS movendo a workload para uma instância habilitada para leituras otimizadas. O Optimized Reads também está disponível por padrão em todas as classes de instância compatíveis. Se você estiver executando a workload nas instâncias db.r5d, db.m5d, db.r6gd, db.m6gd, X2idn e X2iedn, já está se beneficiando do Optimized Reads.