Perguntas frequentes sobre o HAQM RDS for MySQL

Atualmente, o HAQM Relational Database (HAQM RDS) para MySQL oferece suporte às versões 8.4 e 8.0 do MySQL Community Edition. O RDS for MySQL também oferece suporte ao MySQL 5.7 sob o RDS Extended Support. Você pode encontrar mais informações sobre as versões secundárias compatíveis disponíveis no Guia do usuário do HAQM RDS.

No contexto do MySQL, números de versão são organizados da seguinte forma:
Versão do MySQL = X.Y.Z

X = Versão principal, Y = Nível de lançamento, Z = Número de versão dentro da série de lançamento.
Do ponto de vista do HAQM RDS, uma alteração de versão será considerada principal se a versão principal ou o nível de lançamento forem alterados. Exemplo: da versão 5.6.X para a versão 5.7.X.

Uma alteração de versão será considerada secundária se o número da versão dentro da release for alterado. Exemplo: da versão 5.6.27 para a versão 5.6.29.

Sim. Consulte as Perguntas frequentes sobre o HAQM RDS.

A restauração pontual, a restauração de snapshots e os atributos de Integração ETL zero com o HAQM Redshift do HAQM RDS para MySQL exigem um mecanismo de armazenamento recuperável quanto a falhas e apenas são compatíveis com o mecanismo de armazenamento InnoDB. Enquanto o MySQL é compatível com vários mecanismos de armazenamento com recursos variados, nem todos eles são otimizados para durabilidade de dados e recuperação de falha. Por exemplo, o mecanismo de armazenamento MyISAM não oferece suporte à recuperação confiável de falhas e pode resultar em perda ou corrupção de dados quando o MySQL é reiniciado após uma falha, impedindo que a restauração pontual ou a restauração de snapshots funcione conforme o esperado. No entanto, se você ainda optar por usar o MyISAM com o HAQM RDS, poderá ser útil seguir estas etapas em determinados cenários da funcionalidade de restauração de snapshots de banco de dados. Atualmente, o Federated Storage Engine não é compatível com o RDS para MySQL.

Ao criar uma nova instância de banco de dados, o usuário primário padrão que você utilizar obterá certos privilégios. Consulte Privilégios da conta de usuário primário no Guia do usuário do HAQM RDS para obter uma lista de privilégios.

Réplicas de leitura do RDS para MySQL exigem um mecanismo de armazenamento transacional e somente têm suporte pelo mecanismo de armazenamento InnoDB. Mecanismos de armazenamento MySQL não transacionais como o MyISAM podem impedir que as réplicas de leitura funcionem como pretendido. No entanto, se ainda assim escolher usar o MyISAM com Réplicas de leitura, recomendamos que consulte atentamente a métrica "Replica Lag" do HAQM CloudWatch (disponível via AWS Management Console ou APIs do HAQM Cloud Watch) e recrie a Réplica de leitura que deveria ser deixada para trás devido a erros de replicação. As mesmas considerações se aplicam ao uso de tabelas temporárias e qualquer outro mecanismo não transacional.

Você pode definir o formato de registro em log binário para baseado em linha para o MySQL versão 5.6 ou posterior. Por padrão, a replicação é configurada para vários formatos (que incluem com base em linhas e com base em instruções), o que deve atender aos requisitos da maioria dos casos de uso. A documentação do MySQL oferece mais informações sobre a diferença entre as replicações de formatos múltiplos e baseadas em linha.

As implantações azuis/verdes do HAQM RDS estão disponíveis no RDS para MySQL versões 5.7 e superiores. Saiba mais sobre as versões disponíveis na documentação do RDS para MySQL.

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

As implantações azul/verde do HAQM 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.

As implantações azuis/verdes do HAQM 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 de execução em instâncias verdes e azuis inclui o nosso preço padrão atual para instâncias de bancos de dados, custo de armazenamento, custo de leitura/gravação de E/S e todos os atributos habilitados, como o custo de backups e de Insights de Performance do HAQM 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 HAQM Elastic Block Store (HAQM EBS) de uso geral. Você cria um clone da topologia da instância azul usando implantações azuis/verdes do HAQM RDS, executa-a durante 15 dias (360 horas) e depois exclui a instância azul depois de uma transição 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 HAQM 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.

Quando as implantações azuis/verdes do HAQM RDS iniciam uma transição, a gravação é bloqueada em ambos os ambientes, verde e azul, até que a alternância seja concluída. Durante a alternância, o ambiente de preparação, ou ambiente verde, é atualizado com o ambiente azul, garantindo que os dados estejam consistentes entre os ambientes azul e verde. Assim que os ambientes azul e verde estiverem em total sincronia, as implantações azuis/verdes promoverão o ambiente verde como o novo ambiente azul, redirecionando o tráfego para o ambiente verde. 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 HAQM 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 de transição das implantações azuis/verdes do HAQM 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 HAQM RDS não são compatíveis com HAQM 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 HAQM 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 HAQM 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 HAQM RDS estão disponíveis na versão principal MySQL 8.0.30 e posterior do MySQL.

As Gravações otimizadas pelo HAQM RDS estão disponíveis nas instâncias db.r6i e db.r5b. Elas estão disponíveis em todas as regiões em que essas instâncias estão disponíveis, exceto nas regiões da AWS da China.

Todos os usuários do RDS para MySQL devem implementar as Gravações otimizadas pelo HAQM RDS para obter o dobro de throughput em transações de gravação. Esse atributo é especialmente útil para aplicações com workloads que exigem gravação intensa, tais como pagamentos digitais, transações financeiras e aplicações de jogos online.

Não. O HAQM Aurora edição compatível com MySQL já evita usar o “buffer de dupla gravação”. Em vez disso, o 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 as Gravações otimizadas pelo HAQM RDS em suas instâncias de bancos de dados existentes, mesmo que a classe da instância seja compatível com Optimized Writes.

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

Workloads que usam objetos temporários no MySQL para processamento de consultas se beneficiam das Leituras otimizadas pelo HAQM RDS. As Leituras otimizadas posicionam objetos temporários no armazenamento da instância baseada em NVMe, no lugar do volume do HAQM EBS. Isso ajuda a agilizar em até 50% o processamento de consultas complexas.

As Leituras otimizadas pelo HAQM RDS estão disponíveis para RDS para MySQL nas versões MySQL 8.0.28 e posterior.

As Leituras otimizadas pelo HAQM 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 estão disponíveis. Para obter mais informações, consulte a documentação de classes de instâncias de bancos de dados do HAQM RDS.

Os clientes devem usar Leituras otimizadas pelo HAQM RDS quando têm 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 HAQM RDS para usar HAQM RDS Optimized Reads movendo a workload para uma instância habilitada para Optimized Reads. Leituras otimizadas também estão disponíveis 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.

Você deve usar a Integração ETL zero do HAQM RDS para MySQL com o HAQM Redshift quando quiser eliminar a necessidade de criar e gerenciar pipelines de dados complexos. Quando os dados estão no HAQM Redshift, você tem acesso a recursos de analytics e machine learning (ML) quase em tempo real em seus dados transacionais do RDS para MySQL.

A integração ETL zero do RDS para MySQL com o HAQM Redshift está disponível para as versões 8.0.32 e superiores do MySQL nas regiões compatíveis da AWS.

A integração ETL zero do RDS para MySQL com o HAQM Redshift permite analytics e machine learning (ML) quase em tempo real em petabytes de dados transacionais e elimina a necessidade de criar e gerenciar pipelines de dados complexos. Segundos depois de os dados serem gravados no RDS para MySQL, eles são replicados para o HAQM Redshift. Você pode consolidar dados de vários bancos de dados e tabelas do RDS para MySQL no HAQM Redshift. Com base em suas necessidades de analytics, a filtragem de dados de bancos de dados e tabelas específicos ajuda você a trazer dados seletivamente para o HAQM Redshift.

Você paga pelos recursos do RDS para MySQL e do HAQM Redshift usados para criar e processar os dados de alterações criados como parte de uma Integração ETL zero. Esses recursos incluem custos de exportação de snapshots do HAQM RDS para propagar e ressincronizar data warehouses do HAQM Redshift, custos de transferência de dados de captura de dados de alterações (CDC) para replicação contínua de alterações de dados da origem para o destino, E/S e armazenamento regulares do RDS usados para processar dados de alterações e custos regulares de armazenamento e computação do HAQM Redshift para os dados replicados. Para obter mais informações, consulte a página de preços do RDS para MySQL.

Por exemplo: você tem um banco de dados do RDS para MySQL 8.0.32 e um data warehouse do HAQM Redshift em execução na região Leste dos EUA (Norte da Virgínia). Atualmente, essa instância de banco de dados do RDS para MySQL usa 50 GB de capacidade de armazenamento SSD de uso geral (gp3), que inclui IOPS de linha de base provisionadas, além de ter backups automatizados e registro em log binário do MySQL habilitados.

Quando você cria uma Integração ETL zero com o HAQM Redshift para sua instância de banco de dados do RDS para MySQL, um snapshot dos dados (50 GB) é criado e exportado para alimentar um data warehouse do HAQM Redshift. No dia seguinte, você altera a chave primária de uma tabela na sua instância de banco de dados do RDS para MySQL, o que resulta em uma ressincronização da exportação de snapshots para o HAQM Redshift. Ao longo de 30 dias, o banco de dados processa 5 GB de alterações de dados.

Neste exemplo, o custo de usar a Integração ETL zero do RDS para MySQL com o HAQM Redshift no Leste dos EUA (Norte da Virgínia) durante 30 dias é de 50 GB x (USD 0,10) de exportação inicial mais 50 GB x (USD 0,10) de custos de ressincronização mais 5 GB x (USD 2,00/GB) de transferência de dados de CDC, totalizando USD 20,00. Além desses custos da Integração ETL zero, você é responsável pelas cobranças do uso normal do HAQM RDS e do HAQM Redshift para processar os dados replicados, como custos de E/S, armazenamento e computação.

Sim, para reduzir o consumo de recursos na instância primária, você pode usar uma réplica de leitura do HAQM RDS como a instância de origem do HAQM RDS para uma integração ETL zero com o HAQM Redshift.

Sim, você pode usar o AWS CloudFormation para gerenciar e automatizar a configuração e a implantação dos recursos necessários para uma integração ETL zero do RDS para MySQL com o HAQM Redshift. Para obter mais informações, acesse o Guia do usuário do AWS CloudFormation.

A integração ETL zero do RDS para MySQL com o HAQM Redshift replica atomicamente as transações para garantir a consistência de dados entre o banco de dados do RDS para MySQL de origem e o cluster de destino do HAQM Redshift.

Estes são alguns pontos-chave sobre a atomicidade das transações com essa integração:

• Somente transações confirmadas no RDS para MySQL são replicadas para o HAQM Redshift. Transações não confirmadas ou revertidas não são aplicadas.
• A integração usa um processo de confirmação em duas etapas para aplicar atomicamente cada transação ao HAQM Redshift. Todas as alterações de dados na transação são aplicadas ou, se ocorrer um erro, nenhuma transação será aplicada.
• A consistência da transação é mantida entre a origem e o destino. Após a replicação, os dados de uma determinada transação serão consistentes no RDS para MySQL e no HAQM Redshift.
• As alterações de esquema por meio de DDL ou DML também são aplicadas atomicamente para manter a integridade.
• A aplicação atômica das transações garante que nenhuma transação parcial ou estado de dados inconsistente possa ocorrer entre os bancos de dados.

A integração ETL zero do RDS para MySQL com o HAQM Redshift mantém a consistência transacional total entre o banco de dados do RDS para MySQL de origem e o cluster de destino do HAQM Redshift.

Estes são alguns pontos-chave sobre como as mudanças de esquema são tratadas:

• Instruções DDL como CREATE TABLE, ALTER TABLE, DROP TABLE e assim por diante são automaticamente replicadas do RDS para MySQL para o HAQM Redshift.
• A integração faz as verificações e ajustes necessários nas tabelas do HAQM Redshift para alterações de esquema replicadas. Por exemplo, adicionar uma coluna no RDS para MySQL adicionará a coluna no HAQM Redshift.
• A replicação e a sincronização do esquema acontecem automaticamente quase em tempo real, com o mínimo de atraso entre os bancos de dados de origem e de destino.
• A consistência do esquema é mantida mesmo quando as alterações de DML ocorrem paralelamente às alterações de DDL.