# Usar o Amazon Aurora Serverless v1
**Importante**
A AWS anunciou [ a data de fim da vida útil do Aurora Serverless v1: 31 de março de 2025](https://repost.aws/questions/QUhcMVoChXRm2HLi8F-yih1g/announcement-support-for-aurora-s/announcement-support-for-aurora-serverless-v1-ending-soon). Todos os clusters do Aurora Serverless v1 que não forem migrados até 31 de março de 2025 serão migrados para o Aurora Serverless v2 durante a janela de manutenção. Se a atualização falhar, durante a janela de manutenção do Amazon Aurora converterá o cluster do Sem Servidor v1 em um cluster provisionado com a versão de mecanismo equivalente. Se aplicável, o Amazon Aurora inscreverá o cluster provisionado convertido no Suporte estendido do Amazon RDS. Para obter mais informações, consulte [Suporte estendido do Amazon RDS com Amazon Aurora](extended-support.md).
O Amazon Aurora Serverless v1 (Amazon Aurora Serverless versão 1) é uma configuração sob demanda e de autoescalabilidade do Amazon Aurora. Um *cluster de banco de dados do Aurora Serverless v1* é um cluster de banco de dados que dimensiona a capacidade computacional com base nas necessidades de sua aplicação. Isso contrasta com os *clusters de banco de dados provisionados do Aurora*, para os quais você gerencia a capacidade manualmente. O Aurora Serverless v1 fornece uma opção relativamente simples e econômica para workloads pouco frequentes, intermitentes ou imprevisíveis. Ele é econômico porque automaticamente inicia, escala a capacidade computacional para corresponder ao uso de sua aplicação e desliga quando não está em uso.
Para saber mais sobre preços, consulte [Preços de recursos sem servidor](https://aws.amazon.com/rds/aurora/pricing/) em **Edição compatível com MySQL** ou **Edição compatível com PostgreSQL** na página Amazon Aurora pricing.
Aurora Serverless v1Os clusters do têm o mesmo tipo de volume de armazenamento de alta capacidade, distribuído e altamente disponível que é usado por clusters de banco de dados provisionados.
Para um cluster do Aurora Serverless v1, o volume do cluster é sempre criptografado. É possível escolher a chave de criptografia, mas não é possível desabilitar a criptografia. Isso significa que você pode executar as mesmas operações em um Aurora Serverless v1 que você pode em snapshots criptografados. Para obter mais informações, consulte [Aurora Serverless v1 e snapshots](aurora-serverless-v1.how-it-works.md#aurora-serverless.snapshots).
**Topics**
+ [Disponibilidade de regiões e versões do Aurora Serverless v1](#aurora-serverless-v1-Availability)
+ [Vantagens do Aurora Serverless v1](#aurora-serverless-v1.advantages)
+ [Casos de uso do Aurora Serverless v1](#aurora-serverless-v1.use-cases)
+ [Limitações do Aurora Serverless v1](#aurora-serverless.limitations)
+ [Requisitos de configuração do Aurora Serverless v1](#aurora-serverless-v1.requirements)
+ [Usar TLS/SSL com o Aurora Serverless v1](#aurora-serverless.tls)
+ [Como funciona o Aurora Serverless v1](aurora-serverless-v1.how-it-works.md)
+ [Criar um cluster de banco de dados do Aurora Serverless v1](aurora-serverless.create.md)
+ [Restaurar um cluster de banco de dados do Aurora Serverless v1](aurora-serverless.restorefromsnapshot.md)
+ [Modificar um cluster de banco de dados do Aurora Serverless v1](aurora-serverless.modifying.md)
+ [Dimensionar manualmente a capacidade do cluster de banco de dados do Aurora Serverless v1](aurora-serverless.setting-capacity.md)
+ [Visualizar clusters de banco de dados do Aurora Serverless v1](aurora-serverless.viewing.md)
+ [Excluir um cluster de banco de dados do Aurora Serverless v1](aurora-serverless.delete.md)
+ [Aurora Serverless v1Versões de mecanismos de banco de dados do e do Aurora](aurora-serverless.relnotes.md)
## Disponibilidade de regiões e versões do Aurora Serverless v1
A disponibilidade e a compatibilidade de recursos variam entre versões específicas de cada mecanismo de banco de dados do Aurora e entre Regiões da AWS. Para obter mais informações sobre a disponibilidade de versões e regiões com o Aurora e Aurora Serverless v1, consulte [Aurora Serverless v1 da](Concepts.Aurora_Fea_Regions_DB-eng.Feature.ServerlessV1.md).
## Vantagens do Aurora Serverless v1
Aurora Serverless v1O oferece as seguintes vantagens:
+ **Mais simples do que o modelo provisionado**: o Aurora Serverless v1 elimina muito da complexidade e gerenciar instâncias de banco de dados e capacidade.
+ **Escalável**: o Aurora Serverless v1 escala perfeitamente a capacidade de computação e de memória, conforme necessário, sem interrupções nas conexões do cliente.
+ **Econômico**: ao usar o Aurora Serverless v1, você paga apenas pelos recursos de banco de dados que consome, por segundo.
+ **Armazenamento de alta disponibilidade**: o Aurora Serverless v1 usa o mesmo sistema de armazenamento distribuído e tolerante a falhas com replicação de seis maneiras que o Aurora para se proteger contra a perda de dados.
## Casos de uso do Aurora Serverless v1
Aurora Serverless v1O foi projetado para os seguintes casos de uso:
+ **Aplicações usadas com pouca frequência**:você tem uma aplicação que é usada somente por alguns minutos várias vezes por dia ou por semana, como um site de blog de volume baixo. Com o Aurora Serverless v1, você paga apenas pelos recursos de banco de dados que consome, por segundo.
+ **Novas aplicações**:você está implantando uma nova aplicação e não tem certeza sobre o tamanho da instância de que precisa. Com o Aurora Serverless v1, é possível criar um endpoint de banco de dados e fazer a escalabilidade automática para os requisitos de capacidade do banco de dados de sua aplicação.
+ **Workloads variáveis**:você está executando uma aplicação pouco usada, com picos de 30 minutos a várias horas algumas vezes por dia ou várias vezes por ano. Os exemplos são aplicações de recursos humanos, orçamentos e aplicações de relatórios operacionais. Com o Aurora Serverless v1, não é mais necessário provisionar para capacidade de pico ou média.
+ **Workloads imprevisíveis** – você está executando workloads diárias que têm aumentos repentinos e imprevisíveis na atividade. Um exemplo é um site de tráfego que tem um surto de atividades quando começa a chover. Com o Aurora Serverless v1, seu banco de dados faz escalabilidade automática da capacidade para atender às necessidades da carga de pico da aplicação e escala novamente para reduzir a capacidade quando o surto de atividades acaba.
+ **Bancos de dados de desenvolvimento e teste** – os desenvolvedores usam os bancos de dados durante as horas de trabalho, mas não precisam deles à noite ou em fins de semana. Com o Aurora Serverless v1, seu banco de dados é desligado automaticamente quando não está em uso.
+ **Multi-tenant applications** (Aplicações multilocatários): com o Aurora Serverless v1, não é necessário gerenciar individualmente a capacidade do banco de dados para cada aplicação em sua frota. O Aurora Serverless v1 gerencia a capacidade do banco de dados individual para você.
## Limitações do Aurora Serverless v1
As limitações a seguir se aplicam ao Aurora Serverless v1:
+
**Importante**
A AWS anunciou [ a data de fim da vida útil do Aurora Serverless v1: 31 de março de 2025](https://repost.aws/questions/QUhcMVoChXRm2HLi8F-yih1g/announcement-support-for-aurora-s/announcement-support-for-aurora-serverless-v1-ending-soon). Todos os clusters do Aurora Serverless v1 que não forem migrados até 31 de março de 2025 serão migrados para o Aurora Serverless v2 durante a janela de manutenção. Se a atualização falhar, durante a janela de manutenção do Amazon Aurora converterá o cluster do Sem Servidor v1 em um cluster provisionado com a versão de mecanismo equivalente. Se aplicável, o Amazon Aurora inscreverá o cluster provisionado convertido no Suporte estendido do Amazon RDS. Para obter mais informações, consulte [Suporte estendido do Amazon RDS com Amazon Aurora](extended-support.md).
+ Aurora Serverless v1O não é compatível com os seguintes recursos:
+ Bancos de dados globais do Aurora
+ Réplicas do Aurora
+ AWS Identity and Access ManagementAutenticação do banco de dados do (IAM)
+ Retroceder no Aurora
+ Fluxos de atividades do banco de dados
+ Autenticação de Kerberos
+ Insights de Performance
+ RDS Proxy
+ Visualizar logs no Console de gerenciamento da AWS
+ As conexões com um cluster de banco de dados do Aurora Serverless v1 são encerradas automaticamente se permanecerem abertas por mais de um dia.
+ Todos os clusters de banco de dados Aurora Serverless v1 têm as seguintes limitações:
+ Não é possível exportar snapshots do Aurora Serverless v1 para buckets do Amazon S3.
+ Você não pode usar AWS Database Migration Service e Captura de dados de alteração (CDC) com clusters de banco de dados Aurora Serverless v1. Somente os clusters de bancos de dados Aurora provisionados oferecem suporte ao CDC tendo o AWS DMS como origem.
+ Não é possível salvar dados em arquivos de texto no Amazon S3 nem carregar dados de arquivos de texto para o Aurora Serverless v1 do S3.
+ Não é possível anexar um perfil do IAM a um cluster de banco de dados do Aurora Serverless v1. No entanto, você pode carregar dados no Aurora Serverless v1, por meio do Amazon S3, usando a extensão `aws_s3` com a função `aws_s3.table_import_from_s3` e o parâmetro `credentials`. Para obter mais informações, consulte [Importar dados do Amazon S3 para um cluster de banco de dados do Aurora PostgreSQL](USER_PostgreSQL.S3Import.md).
+ Ao usar o editor de consultas, um segredo do Secrets Manager é criado para que as credenciais do banco de dados acessem o banco de dados. Se você excluir as credenciais do editor de consultas, o segredo associado também será excluído do Secrets Manager. Não é possível recuperar esse segredo após sua exclusão.
+ Os clusters de banco de dados baseados em Aurora MySQL que executam o Aurora Serverless v1 não são compatíveis com:
+ Invocar funções do AWS Lambda de dentro do cluster de bancos de dados Aurora MySQL. No entanto, as funções do AWS Lambda podem fazer chamadas para o cluster de banco de dados do Aurora Serverless v1.
+ Restauração de um snapshot de uma instância de banco de dados que não seja do Aurora MySQL ou RDS para MySQL.
+ Replicação de dados usando replicação com base em logs binários (binlogs). Essa limitação é verdadeira, não importa se o cluster de banco de dados do Aurora Serverless v1 baseado em Aurora MySQL é a origem ou o destino da replicação. Para replicar dados em um cluster de banco de dados do Aurora Serverless v1 de uma instância de banco de dados MySQL fora do Aurora, como uma em execução no Amazon EC2, avalie a possibilidade de usar o AWS Database Migration Service. Para obter mais informações, consulte o [Guia do usuário do AWS Database Migration Service](https://docs.aws.amazon.com/dms/latest/userguide/).
+ Criar usuários com acesso baseado em host (`'username'@'IP_address'`). Isso ocorre porque o Aurora Serverless v1 usa uma frota de roteadores entre o cliente e o host do banco de dados para uma escalabilidade perfeita. O endereço IP que o cluster de banco de dados do Aurora Serverless vê é o do host do roteador, não do seu cliente. Para obter mais informações, consulte [Aurora Serverless v1Arquitetura do](aurora-serverless-v1.how-it-works.md#aurora-serverless.architecture).
Em vez disso, use o caractere curinga (`'username'@'%'`).
+ Os clusters de banco de dados baseados no Aurora PostgreSQL que executam o Aurora Serverless v1 têm as seguintes limitações:
+ O gerenciamento de planos de consulta do Aurora PostgreSQL (extensão `apg_plan_management`) não é aceito.
+ Não há suporte ao recurso de replicação lógica disponível no Amazon RDS PostgreSQL e no Aurora PostgreSQL.
+ Não há suporte a comunicações de saída como as habilitadas pelas extensões do Amazon RDS para PostgreSQL. Por exemplo, não é possível acessar dados externos com a extensão `postgres_fdw/dblink`. Para obter mais informações sobre as extensões PostgreSQL do RDS, consulte [PostgreSQL no Amazon RDS](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/CHAP_PostgreSQL.html#PostgreSQL.Concepts.General.FeatureSupport.Extensions.101x) no *Guia do usuário do RDS*.
+ Atualmente, determinadas consultas e comandos SQL não são recomendados. Estes incluem bloqueios de aconselhamento em nível de sessão, relações temporárias, notificações assíncronas (`LISTEN`) e cursores com retenção (`DECLARE name ... CURSOR WITH HOLD FOR query`). Além disso, os comandos `NOTIFY` impedem a escalabilidade e não são recomendados.
Para obter mais informações, consulte [Autoscaling for Aurora Serverless v1](aurora-serverless-v1.how-it-works.md#aurora-serverless.how-it-works.auto-scaling).
+ Não é possível definir a janela de backup automatizado preferencial para um cluster de banco de dados do Aurora Serverless v1.
+ Você pode definir a janela de manutenção para um cluster de banco de dados do Aurora Serverless v1. Para obter mais informações, consulte [Ajustar a janela de manutenção do cluster de banco de dados preferencial](USER_UpgradeDBInstance.Maintenance.md#AdjustingTheMaintenanceWindow.Aurora).
## Requisitos de configuração do Aurora Serverless v1
Ao criar um cluster de banco de dados do Aurora Serverless v1, preste atenção aos seguintes requisitos:
+ Use estes números de porta específicos para cada mecanismo de banco de dados:
+ Aurora MySQL – `3306`
+ Aurora PostgreSQL – `5432`
+ Crie seu cluster de banco de dados do Aurora Serverless v1 em uma nuvem privada virtual (VPC) com base no serviço da Amazon VPC. Ao criar um cluster de banco de dados do Aurora Serverless v1 em sua VPC, você consome 2 (dois) dos 50 (cinquenta) endpoints de interface e do balanceador de carga do Gateway alocados à VPC. Esses endpoints são criados automaticamente para você. Para aumentar sua cota, você pode entrar em contato com Suporte. Para obter mais informações, consulte as [Amazon VPC cotas](https://docs.aws.amazon.com/vpc/latest/userguide/amazon-vpc-limits.html#vpc-limits-endpoints).
+ Não é possível fornecer um endereço IP público a um cluster de banco de dados do Aurora Serverless v1. Você pode acessar um cluster de banco de dados do Aurora Serverless v1 somente a partir de uma VPC.
+ Crie sub-redes em diferentes zonas de disponibilidade para o grupo de sub-redes de banco de dados que você usa para seu cluster de banco de dados Aurora Serverless v1. Em outras palavras, não é possível ter mais do que uma sub-rede na mesma zona de disponibilidade.
+ As alterações feitas em um grupo de sub-redes usado por um cluster de banco de dados do Aurora Serverless v1 não são aplicadas ao cluster.
+ É possível acessar um cluster de banco de dados do Aurora Serverless v1 no AWS Lambda. Para isso, é necessário configurar a função do Lambda para ser executada na mesma VPC que o cluster de banco de dados do Aurora Serverless v1. Para obter mais informações sobre como trabalhar com o AWS Lambda, consulte [Configurar uma função do Lambda para acessar recursos em uma Amazon VPC](https://docs.aws.amazon.com/lambda/latest/dg/vpc.html) no *Guia do desenvolvedor do AWS Lambda*.
## Usar TLS/SSL com o Aurora Serverless v1
Por padrão, o Aurora Serverless v1 usa o protocolo Transport Layer Security/Secure Sockets Layer (TLS/SSL) para criptografar as comunicações entre clientes e seu cluster de banco de dados Aurora Serverless v1. Ele é compatível com TLS/SSL versões 1.0, 1.1 e 1.2. Você não precisa configurar seu cluster de banco de dados do Aurora Serverless v1 para usar TLS/SSL.
No entanto, as seguintes limitações se aplicam:
+ A compatibilidade com TLS/SSL para clusters de banco de dados do Aurora Serverless v1 não está disponível atualmente na região China (Pequim) da Região da AWS.
+ Quando você cria usuários de banco de dados para um cluster de banco de dados do Aurora Serverless v1 baseado no Aurora MySQL, não use a cláusula `REQUIRE` para permissões SSL. Isso impede que os usuários se conectem à instância de bancos de dados Aurora.
+ Para os utilitários MySQL Client e PostgreSQL Client, as variáveis de sessão que você pode usar em outros ambientes não têm efeito ao usar TLS/SSL entre o cliente e o Aurora Serverless v1.
+ Para o MySQL Client, ao se conectar com o modo `VERIFY_IDENTITY` do TLS/SSL, atualmente você precisa usar o comando `mysql` compatível com o MySQL 8.0. Para obter mais informações, consulte [Conexão a uma instância de banco de dados executando o mecanismo de banco de dados do MySQL](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_ConnectToInstance.html).
Dependendo do cliente usado para se conectar ao cluster de banco de dados do Aurora Serverless v1, talvez você não precise especificar TLS/SSL para obter uma conexão criptografada. Por exemplo, para usar o cliente PostgreSQL para se conectar a um cluster de banco de dados do Aurora Serverless v1 que executa o Aurora Edição compatível com PostgreSQL, conecte-se como você normalmente faz.
```
psql -h endpoint -U user
```
Depois de digitar sua senha, o cliente PostgreSQL mostra que você vê os detalhes da conexão, incluindo a versão TLS/SSL e a cifra.
```
psql (12.5 (Ubuntu 12.5-0ubuntu0.20.04.1), server 10.12)
SSL connection (protocol: TLSv1.2, cipher: ECDHE-RSA-AES256-GCM-SHA384, bits: 256, compression: off)
Type "help" for help.
```
**Importante**
Aurora Serverless v1O usa o protocolo TLS/SSL (Transport Layer Security/Secure Sockets Layer) para criptografar conexões por padrão, a menos que o TLS/SSL seja desabilitado pela aplicação cliente. A conexão TLS/SSL termina na frota de roteadores. A comunicação entre a frota de roteadores e seu cluster de banco de dados do Aurora Serverless v1 ocorre dentro do limite interno da rede do serviço.
É possível conferir o status da conexão do cliente para examinar se a conexão com o Aurora Serverless v1 está criptografada com TLS/SSL. As tabelas `pg_stat_ssl` e `pg_stat_activity` do PostgreSQL e sua função `ssl_is_used` não mostram o estado TLS/SSL da comunicação entre a aplicação cliente e o Aurora Serverless v1. Da mesma forma, o estado TLS/SSL não pode ser derivado da instrução `status` do MySQL.
Anteriormente, os parâmetros de cluster do Aurora `force_ssl` para PostgreSQL e `require_secure_transport` para MySQL não eram compatíveis com o Aurora Serverless v1. Esses parâmetros já estão disponíveis para o Aurora Serverless v1. Para obter uma lista completa dos parâmetros compatíveis com o Aurora Serverless v1, chame a operação de API [DescribeEngineDefaultClusterParameters](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_DescribeEngineDefaultClusterParameters.html). Para obter mais informações sobre grupos de parâmetros e o Aurora Serverless v1, consulte [Grupos de parâmetros para Aurora Serverless v1](aurora-serverless-v1.how-it-works.md#aurora-serverless.parameter-groups).
Para usar o MySQL Client para se conectar a um cluster de banco de dados do Aurora Serverless v1 que executa o Aurora Edição compatível com MySQL, especifique o TLS/SSL em sua solicitação. O exemplo a seguir inclui o [armazenamento de confiança CA 1 raiz da Amazon](https://www.amazontrust.com/repository/AmazonRootCA1.pem) baixado do Amazon Trust Services, que é necessário para que essa conexão seja bem-sucedida.
```
mysql -h endpoint -P 3306 -u user -p --ssl-ca=amazon-root-CA-1.pem --ssl-mode=REQUIRED
```
Insira sua senha quando for solicitado. Logo, o monitor MySQL será aberto. Você pode confirmar que a sessão está criptografada usando o comando `status`.
```
mysql> status
--------------
mysql Ver 14.14 Distrib 5.5.62, for Linux (x86_64) using readline 5.1
Connection id: 19
Current database:
Current user: ***@*******
SSL: Cipher in use is ECDHE-RSA-AES256-SHA
...
```
Para saber mais sobre como se conectar ao banco de dados do Aurora MySQL com o cliente MySQL, consulte [Conectar-se a uma instância de banco de dados que esteja executando o mecanismo de banco de dados MySQL.](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_ConnectToInstance.html).
O Aurora Serverless v1 é compatível com todos os modos TLS/SSL disponíveis para o cliente do MySQL (`mysql`) e o cliente do PostgreSQL (`psql`), incluindo aqueles listados na tabela a seguir.
| Descrição do modo TLS/SSL | mysql | psql |
| --- | --- | --- |
| Conectar sem usar TLS/SSL. | DISABLED | desabilitar |
| Tente a conexão usando TLS/SSL primeiro, mas volte para não SSL, se necessário. | PREFERRED | preferir (padrão) |
| Imponha o uso de TLS/SSL. | REQUIRED | require |
| Imponha o TLS/SSL e verifique a CA. | VERIFY\$1CA | verify-ca |
| Imponha o TLS/SSL, verifique a CA e verifique o hostname da CA. | VERIFY\$1IDENTITY | verify-full |
Aurora Serverless v1O usa certificados curinga. Se você especificar a opção “verificar CA” ou “verificar CA e nome do host da CA” ao usar TLS/SSL, primeiro baixe o [armazenamento de confiança CA 1 raiz da Amazon](https://www.amazontrust.com/repository/AmazonRootCA1.pem) no Amazon Trust Services. Depois de fazer isso, você pode identificar esse arquivo formatado em PEM em seu comando client. Para fazer isso usando o PostgreSQL Client:
Para Linux, macOS ou Unix:
```
psql 'host=endpoint user=user sslmode=require sslrootcert=amazon-root-CA-1.pem dbname=db-name'
```
Para saber mais sobre como trabalhar com o banco de dados do Aurora PostgreSQL usando o cliente do Postgres, consulte [Conectar-se a uma instância de banco de dados que esteja executando o mecanismo de banco de dados do PostgreSQL.](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_ConnectToPostgreSQLInstance.html).
Para obter mais informações sobre como se conectar a clusters de bancos de dados Aurora em geral, consulte [Como conectar-se a um cluster de bancos de dados Amazon Aurora](Aurora.Connecting.md).
### Pacotes de cifras compatíveis com clusters de banco de dados do Aurora Serverless v1
Usando conjuntos de cifras configuráveis, você pode ter mais controle sobre a segurança de suas conexões de banco de dados. É possível especificar uma lista de conjuntos de cifras que você deseja permitir para proteger conexões TLS/SSL do cliente com o banco de dados. Com conjuntos de cifras configuráveis, você pode controlar a criptografia de conexão aceita pelo servidor de banco de dados. Isso impede o uso de cifras que não são seguras ou que não são mais usadas.
Aurora Serverless v1Os clusters de banco de dados do que são baseados no Aurora MySQL são compatíveis com os mesmos conjuntos de cifras que os clusters de banco de dados provisionados pelo Aurora MySQL. Para obter informações sobre esses conjuntos de cifras, consulte [Configurar conjuntos de criptografia para conexões com clusters de banco de dados do Aurora MySQL](AuroraMySQL.Security.md#AuroraMySQL.Security.SSL.ConfiguringCipherSuites).
Aurora Serverless v1Os clusters de banco de dados do baseados no Aurora PostgreSQL não são compatíveis com conjuntos de cifras.
# Como funciona o Aurora Serverless v1
**Importante**
A AWS anunciou [ a data de fim da vida útil do Aurora Serverless v1: 31 de março de 2025](https://repost.aws/questions/QUhcMVoChXRm2HLi8F-yih1g/announcement-support-for-aurora-s/announcement-support-for-aurora-serverless-v1-ending-soon). Todos os clusters do Aurora Serverless v1 que não forem migrados até 31 de março de 2025 serão migrados para o Aurora Serverless v2 durante a janela de manutenção. Se a atualização falhar, durante a janela de manutenção do Amazon Aurora converterá o cluster do Sem Servidor v1 em um cluster provisionado com a versão de mecanismo equivalente. Se aplicável, o Amazon Aurora inscreverá o cluster provisionado convertido no Suporte estendido do Amazon RDS. Para obter mais informações, consulte [Suporte estendido do Amazon RDS com Amazon Aurora](extended-support.md).
A seguir, saiba como funciona o Aurora Serverless v1.
**Topics**
+ [Aurora Serverless v1Arquitetura do](#aurora-serverless.architecture)
+ [Autoscaling for Aurora Serverless v1](#aurora-serverless.how-it-works.auto-scaling)
+ [Ação de tempo limite para alterações na capacidade](#aurora-serverless.how-it-works.timeout-action)
+ [Pausa e retomada para o Aurora Serverless v1](#aurora-serverless.how-it-works.pause-resume)
+ [Determinar o número máximo de conexões de banco de dados do Aurora Serverless v1](#aurora-serverless.max-connections)
+ [Grupos de parâmetros para Aurora Serverless v1](#aurora-serverless.parameter-groups)
+ [Registro em log para o Aurora Serverless v1](#aurora-serverless.logging)
+ [Aurora Serverless v1 e manutenção](#aurora-serverless.maintenance)
+ [Aurora Serverless v1 e failover](#aurora-serverless.failover)
+ [Aurora Serverless v1 e snapshots](#aurora-serverless.snapshots)
## Aurora Serverless v1Arquitetura do
A imagem a seguir mostra uma visão geral da arquitetura do Aurora Serverless v1.
![\[Aurora Serverless v1Arquitetura do\]](http://docs.aws.amazon.com/pt_br/AmazonRDS/latest/AuroraUserGuide/images/aurora-serverless-arch.png)
Em vez de provisionar e gerenciar servidores de banco de dados, você especifica capacity units (ACUs - unidades de capacidade) do Aurora. Cada ACU é uma combinação de aproximadamente 2 gigabytes (GB) de memória, CPU correspondente e rede. O armazenamento do banco de dados escala automaticamente de 10 gibibytes (GiB) para 128 tebibytes (TiB), o mesmo que o armazenamento em um cluster de banco de dados padrão do Aurora.
Você pode especificar as ACUs mínima e máxima. A *unidade de capacidade mínima do Aurora* é a ACU mais baixa para a qual o cluster de banco de dados pode ser reduzido. A *unidade de capacidade máxima do Aurora* é a ACU mais alta para a qual o cluster de banco de dados pode ser expandido. Com base em suas configurações, o Aurora Serverless v1 cria automaticamente as regras de escalabilidade para os limites de utilização de CPU, conexões e memória disponível.
O Aurora Serverless v1 gerencia o grupo quente de recursos em uma Região da AWS para minimizar o tempo de escalabilidade. Quando o Aurora Serverless v1 adiciona recursos ao cluster de bancos de dados Aurora, ele usa a frota de roteadores para alternar as conexões de clientes ativas para os novos recursos. Em algum momento específico, você será cobrado somente pelas ACUs que estão sendo usadas ativamente em seu cluster de banco de dados do Aurora.
## Autoscaling for Aurora Serverless v1
A capacidade alocada para o cluster de banco de dados do Aurora Serverless v1 é expandida ou reduzida perfeitamente com base na carga gerada pela aplicação cliente. Aqui, a carga é a utilização da CPU e a quantidade de conexões. Quando a capacidade é limitada por qualquer um desses, o Aurora Serverless v1 se expande. O Aurora Serverless v1 também se expande quando detecta problemas de performance que podem ser resolvidos ao fazê-lo.
Você pode visualizar eventos de escalabilidade de seu cluster do Aurora Serverless v1 no Console de gerenciamento da AWS. Durante a escalabilidade automática, o Aurora Serverless v1 redefine a métrica `EngineUptime`. O valor da métrica de redefinição não significa que a escalabilidade contínua tenha problemas nem que o Aurora Serverless v1 descartou conexões. É simplesmente o ponto de partida para o tempo de atividade na nova capacidade. Para saber mais sobre as métricas, consulte [Monitorar métricas em um cluster do Amazon Aurora](MonitoringAurora.md).
Quando o seu cluster de banco de dados do Aurora Serverless v1 não tem conexões ativas, ele pode reduzir até a capacidade zero (0 ACUs). Para saber mais, consulte [Pausa e retomada para o Aurora Serverless v1](#aurora-serverless.how-it-works.pause-resume).
Quando é preciso executar uma operação de escalabilidade, o Aurora Serverless v1 primeiro tenta identificar um * ponto de escalabilidade*, um momento em que nenhuma consulta esteja em processamento. O Aurora Serverless v1 talvez não consiga encontrar um ponto de escalabilidade pelos seguintes motivos:
+ Consultas de longa duração
+ Transações em andamento
+ As tabelas temporárias ou bloqueios de tabela estão em uso
Para aumentar a taxa de sucesso em encontrar um ponto de escalabilidade de seu cluster de banco de dados Aurora Serverless v1, recomendamos evitar consultas e transações de longa duração. Para saber mais sobre operações que impedem a escalabilidade e como evitá-las, consulte [Práticas recomendadas para trabalhar com o Aurora Serverless v1](https://aws.amazon.com/blogs/database/best-practices-for-working-with-amazon-aurora-serverless/).
Por padrão, o Aurora Serverless v1 tenta encontrar um ponto de escalabilidade por cinco minutos (300 segundos). É possível especificar um período de tempo limite diferente ao criar ou modificar o cluster. O tempo limite pode ter entre 60 segundos e 10 minutos (600 segundos). Se o Aurora Serverless v1 não conseguir encontrar um ponto de escalabilidade no período especificado, o tempo limite da operação de autoescalabilidade é excedido.
Por padrão, se a autoescalabilidade não encontrar um ponto de escalabilidade antes do tempo limite, o Aurora Serverless v1 manterá o cluster na capacidade atual. Você pode alterar esse comportamento padrão ao criar ou modificar o seu cluster de banco de dados do Aurora Serverless v1 selecionando a opção **Force the capacity change** (Forçar a alteração da capacidade). Para ter mais informações, consulte [Ação de tempo limite para alterações na capacidade](#aurora-serverless.how-it-works.timeout-action).
## Ação de tempo limite para alterações na capacidade
Se a autoescalabilidade ultrapassar o tempo limite sem encontrar um ponto de escalabilidade, por padrão, o Aurora manterá a capacidade atual. Você pode optar por deixar o Aurora forçar a alteração selecionando a opção **Force the capacity change** (Forçar a alteração de capacidade). Essa opção está disponível na seção **Autoscaling timeout and action** (Tempo limite e ação de autoescalabilidade) da página **Create database** (Criar banco de dados), quando você cria o cluster.
Por padrão, a opção **Force the capacity change** (Forçar a alteração de capacidade) não é selecionada. Deixe essa opção desmarcada para que a capacidade do cluster de banco de dados do Aurora Serverless v1 permaneça inalterada, se a operação de escalabilidade ultrapassar o tempo limite sem encontrar um ponto de escalabilidade.
Selecionar essa opção faz com que o cluster de banco de dados do Aurora Serverless v1 imponha a alteração de capacidade, mesmo sem um ponto de escalabilidade. Antes de selecionar esta opção, lembre-se consequências dessa seleção:
+ Quaisquer transações em andamento são interrompidas e a seguinte mensagem de erro é exibida.
Aurora MySQL versão 2 – ERRO 1105 (HY000): A última transação foi interrompida devido à escalabilidade simples. Tente novamente.
Você pode reenviar as transações assim que seu cluster de banco de dados do Aurora Serverless v1 estiver disponível.
+ As conexões com tabelas temporárias e bloqueios são descartadas.
Recomendamos que você selecione a opção **Force the capacity change** (Forçar a alteração da capacidade) somente se sua aplicação puder se recuperar de conexões descartadas ou transações incompletas.
As escolhas que você faz no Console de gerenciamento da AWS ao criar um cluster de banco de dados do Aurora Serverless v1 são armazenadas no objeto `ScalingConfigurationInfo`, nas propriedades `SecondsBeforeTimeout` e `TimeoutAction`. O valor da propriedade `TimeoutAction` é definido como um dos seguintes valores quando você cria o cluster:
+ `RollbackCapacityChange`: este valor é definido quando você seleciona a opção **Roll back the capacity change** (Reverter a alteração na capacidade). Esse é o comportamento padrão.
+ `ForceApplyCapacityChange`: este valor é definido quando você seleciona a opção **Force the capacity change** (Forcar a alteração da capacidade).
Você pode obter o valor dessa propriedade em um cluster de banco de dados do Aurora Serverless v1 existente usando o comando [describe-db-clusters](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-db-clusters.html) da AWS CLI, como mostrado a seguir.
Para Linux, macOS ou Unix:
```
aws rds describe-db-clusters --region region \
--db-cluster-identifier your-cluster-name \
--query '*[].{ScalingConfigurationInfo:ScalingConfigurationInfo}'
```
Para Windows:
```
aws rds describe-db-clusters --region region ^
--db-cluster-identifier your-cluster-name ^
--query "*[].{ScalingConfigurationInfo:ScalingConfigurationInfo}"
```
O exemplo a seguir mostra a consulta e a resposta de um cluster de banco de dados do Aurora Serverless v1 chamado `west-coast-sles` na região Oeste dos EUA (Norte da Califórnia).
```
$ aws rds describe-db-clusters --region us-west-1 --db-cluster-identifier west-coast-sles
--query '*[].{ScalingConfigurationInfo:ScalingConfigurationInfo}'
[
{
"ScalingConfigurationInfo": {
"MinCapacity": 1,
"MaxCapacity": 64,
"AutoPause": false,
"SecondsBeforeTimeout": 300,
"SecondsUntilAutoPause": 300,
"TimeoutAction": "RollbackCapacityChange"
}
}
]
```
Como mostra a resposta, esse cluster de banco de dados do Aurora Serverless v1 usa a configuração padrão.
Para ter mais informações, consulte [Criar um cluster de banco de dados do Aurora Serverless v1](aurora-serverless.create.md). Após criar seu Aurora Serverless v1, você também pode modificar a ação de tempo limite e outras configurações de capacidade a qualquer momento. Para saber como, consulte [Modificar um cluster de banco de dados do Aurora Serverless v1](aurora-serverless.modifying.md).
## Pausa e retomada para o Aurora Serverless v1
É possível escolher pausar o cluster de banco de dados do Aurora Serverless v1 depois de um certo tempo sem atividade. Você especifica o tempo sem atividade para que o cluster de banco seja pausado. Ao selecionar essa opção, o tempo de inatividade padrão é cinco minutos, mas é possível alterar esse valor. Esta definição é opcional.
Quando o cluster de banco é pausado, não ocorre nenhuma atividade de computação ou de memória, e você é cobrado somente pelo armazenamento. Se forem solicitadas conexões ao banco de dados quando um cluster de banco de dados do Aurora Serverless v1 estiver pausado, o cluster de banco de dados será retomado automaticamente e atenderá às solicitações de conexão.
Quando o cluster de banco de dados retoma a atividade, ele tem a mesma capacidade que tinha quando o Aurora pausou o cluster. O número de ACUs depende de quanto o Aurora expandiu ou reduziu o cluster antes de pausá-lo.
**nota**
Se um cluster de banco de dados for pausado por mais de sete dias, o backup do cluster de banco de dados poderá ser feito com um snapshot. Nesse caso, o Aurora restaura o cluster de banco de dados do snapshot quando há uma solicitação de conexão.
## Determinar o número máximo de conexões de banco de dados do Aurora Serverless v1
Os exemplos a seguir são de um cluster de banco de dados do Aurora Serverless v1 compatível com o MySQL 5.7. Você pode usar um cliente do MySQL ou o editor de consultas, se tiver configurado o acesso a ele. Para ter mais informações, consulte [Executar consultas no editor de consultas](query-editor.md#query-editor.running).
**Como encontrar o número máximo de conexões de banco de dados**
1. Encontre o intervalo de capacidade de seu cluster de banco de dados do Aurora Serverless v1 usando a AWS CLI.
```
aws rds describe-db-clusters \
--db-cluster-identifier my-serverless-57-cluster \
--query 'DBClusters[*].ScalingConfigurationInfo|[0]'
```
O resultado mostra que seu intervalo de capacidade é de 1 a 4 ACUs.
```
{
"MinCapacity": 1,
"AutoPause": true,
"MaxCapacity": 4,
"TimeoutAction": "RollbackCapacityChange",
"SecondsUntilAutoPause": 3600
}
```
1. Realize a seguinte consulta SQL para encontrar o número máximo de conexões.
```
select @@max_connections;
```
O resultado mostrado é da capacidade mínima do cluster, 1 ACU.
```
@@max_connections
90
```
1. Dimensione o cluster para 8 a 32 ACUs.
Para ter mais informações sobre a escalabilidade, consulte [Modificar um cluster de banco de dados do Aurora Serverless v1](aurora-serverless.modifying.md).
1. Confirme o intervalo de capacidade.
```
{
"MinCapacity": 8,
"AutoPause": true,
"MaxCapacity": 32,
"TimeoutAction": "RollbackCapacityChange",
"SecondsUntilAutoPause": 3600
}
```
1. Encontre o número máximo de conexões.
```
select @@max_connections;
```
O resultado mostrado é da capacidade mínima do cluster, 8 ACUs.
```
@@max_connections
1000
```
1. Dimensione o cluster para o máximo possível, 256 a 256 ACUs.
1. Confirme o intervalo de capacidade.
```
{
"MinCapacity": 256,
"AutoPause": true,
"MaxCapacity": 256,
"TimeoutAction": "RollbackCapacityChange",
"SecondsUntilAutoPause": 3600
}
```
1. Encontre o número máximo de conexões.
```
select @@max_connections;
```
O resultado mostrado é de 256 ACUs.
```
@@max_connections
6000
```
**nota**
O valor `max_connections` não é dimensionado linearmente com o número de ACUs.
1. Reduza a escala do cluster verticalmente para 1 a 4 ACUs.
```
{
"MinCapacity": 1,
"AutoPause": true,
"MaxCapacity": 4,
"TimeoutAction": "RollbackCapacityChange",
"SecondsUntilAutoPause": 3600
}
```
Dessa vez, o valor `max_connections` é de 4 ACUs.
```
@@max_connections
270
```
1. Reduza a escala do cluster verticalmente para 2 ACUs.
```
@@max_connections
180
```
Se você configurou o cluster para pausar após determinado período de tempo ocioso, a escala será reduzida verticalmente para 0 ACUs. No entanto, o valor `max_connections` não fica abaixo de 1 ACU.
```
@@max_connections
90
```
## Grupos de parâmetros para Aurora Serverless v1
Quando você cria o seu cluster de banco de dados do Aurora Serverless v1, você escolhe um mecanismo de banco de dados do Aurora específico e um grupo de parâmetros de cluster de banco de dados associado. Ao contrário dos clusters de bancos de dados Aurora provisionado, um cluster de banco de dados do Aurora Serverless v1 tem uma única instância de banco de dados de leitura/gravação configurada apenas com um grupo de parâmetros de cluster de banco de dados. Ele não tem um grupo de parâmetros de banco de dados separado. Durante o autoscaling, o Aurora Serverless v1 precisa ser capaz de alterar os parâmetros para que o cluster funcione melhor com a capacidade aumentada ou reduzida. Assim, com um cluster de banco de dados do Aurora Serverless v1, algumas das alterações que você pode fazer nos parâmetros para um determinado tipo de mecanismo de banco de dados podem não se aplicar.
Por exemplo, um cluster de banco de dados do Aurora Serverless v1 baseado no Aurora PostgreSQL não pode usar `apg_plan_mgmt.capture_plan_baselines` e outros parâmetros para gerenciamento de planos de consulta que podem ser usados em clusters de bancos de dados Aurora PostgreSQL provisionados.
Você pode obter uma lista de valores padrão para os grupos de parâmetros padrão dos vários mecanismos de banco de dados do Aurora usando o comando da CLI [describe-engine-default-cluster-parameters](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-engine-default-cluster-parameters.html) e consultando a Região da AWS. A seguir estão os valores que você pode usar para a opção `--db-parameter-group-family`.
| | |
| --- |--- |
| Aurora MySQL versão 2 | `aurora-mysql5.7` |
| Aurora PostgreSQL versão 11 | `aurora-postgresql11` |
| Aurora PostgreSQL versão 13 | `aurora-postgresql13` |
Recomendamos que você configure a AWS CLI com o seu ID de chave de acesso da AWS e a chave de acesso secreta da AWS, além de definir a sua Região da AWS antes de usar os comandos da AWS CLI. Fornecer a região a sua configuração de CLI torna desnecessário inserir o parâmetro `--region` ao executar comandos. Para saber mais sobre como configurar a AWS CLI, consulte [Noções básicas de configuração](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-quickstart.html#cli-configure-quickstart-config) no *Guia do usuário da AWS Command Line Interface*.
O exemplo a seguir obtém uma lista de parâmetros do grupo de clusters de banco de dados padrão para Aurora MySQL versão 2.
Para Linux, macOS ou Unix:
```
aws rds describe-engine-default-cluster-parameters \
--db-parameter-group-family aurora-mysql5.7 --query \
'EngineDefaults.Parameters[*].{ParameterName:ParameterName,SupportedEngineModes:SupportedEngineModes} | [?contains(SupportedEngineModes, `serverless`) == `true`] | [*].{param:ParameterName}' \
--output text
```
Para Windows:
```
aws rds describe-engine-default-cluster-parameters ^
--db-parameter-group-family aurora-mysql5.7 --query ^
"EngineDefaults.Parameters[*].{ParameterName:ParameterName,SupportedEngineModes:SupportedEngineModes} | [?contains(SupportedEngineModes, 'serverless') == `true`] | [*].{param:ParameterName}" ^
--output text
```
### Modificação de valores de parâmetro para o Aurora Serverless v1
Como explicado em [Grupos de parâmetros para Amazon Aurora](USER_WorkingWithParamGroups.md), você não pode alterar diretamente os valores em um grupo de parâmetros padrão, independentemente do tipo (grupo de parâmetros de cluster de banco de dados, grupo de parâmetros de banco de dados). Em vez disso, você cria um grupo de parâmetros personalizado com base no grupo de parâmetros do cluster de banco de dados padrão para o seu mecanismo de banco de dados do Aurora e altera as configurações nesse grupo de parâmetros, conforme necessário. Por exemplo, você pode querer alterar algumas das configurações do cluster de banco de dados do Aurora Serverless v1 para consultas de log do [ ou para fazer upload de logs específicos do mecanismo de banco de dados](#aurora-serverless.logging) para o Amazon CloudWatch.
**Para criar um grupo de parâmetros de cluster de banco de dados personalizado**
1. Faça login no Console de gerenciamento da AWS e abra o console do Amazon RDS em [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/).
1. Escolha **Grupos de parâmetros**.
1. Escolha **Create parameter group (Criar grupo de parâmetros)** para abrir o painel Parameter group details (Detalhes do grupo de parâmetros).
1. Escolha o grupo de cluster de banco de dados padrão apropriado para o mecanismo de banco de dados que você deseja usar para seu cluster de banco de dados do Aurora Serverless v1. Escolha as seguintes opções:
1. Para **Parameter group family (Família de grupo de parâmetros)**, escolha a família apropriada para o mecanismo de banco de dados escolhido. Sua seleção deve ter o prefixo `aurora-` no nome.
1. Em **Type (Tipo)**, escolha **DB Cluster Parameter Group (Grupo de parâmetros do cluster de banco de dados)**.
1. Em **Group name (Nome do grupo)** e **Description (Descrição)**, insira nomes significativos para você ou outras pessoas que possam precisar trabalhar com seu cluster de banco de dados do Aurora Serverless v1 e respectivos parâmetros.
1. Escolha **Criar**.
Seu grupo de parâmetros de cluster de banco de dados personalizado é adicionado à lista de grupos de parâmetros disponíveis em sua Região da AWS. Você pode usar seu grupo de parâmetros de cluster de banco de dados personalizado ao criar clusters de banco de dados do Aurora Serverless v1. Você também pode modificar seus clusters de banco de dados do Aurora Serverless v1 existentes para usar seu grupo de parâmetros de cluster de banco de dados personalizado. Depois que seu cluster de banco de dados do Aurora Serverless v1 começa a usar seu grupo de parâmetros do cluster de banco de dados personalizado, você pode alterar os valores de parâmetros dinâmicos usando o Console de gerenciamento da AWS ou a AWS CLI.
Você também pode usar o console para visualizar uma comparação lado a lado entre os valores no seu grupo de parâmetros do cluster de banco de dados personalizado e no cluster de banco de dados padrão, conforme mostrado no snapshot a seguir.
![\[Logs publicados no CloudWatch Logs para clusters de banco de dados do Aurora Serverless v1 para Aurora MySQL e Aurora PostgreSQL\]](http://docs.aws.amazon.com/pt_br/AmazonRDS/latest/AuroraUserGuide/images/aurora-serverless-custom-db-cluster-param-cf-default.png)
Quando você altera valores de parâmetros em um cluster de banco de dados ativo, o Aurora Serverless v1 inicia uma escalabilidade perfeita para aplicar as alterações de parâmetros. Se o seu cluster de banco de dados do Aurora Serverless v1 estiver em um estado pausado, ele retomará e começará a escalar para que possa fazer a alteração. A operação de escalabilidade para uma alteração de grupo de parâmetros sempre [força a alteração de capacidade](#aurora-serverless.how-it-works.timeout-action), portanto esteja ciente de que a modificação de parâmetros poderá ocasionar conexões descartadas se um ponto de escalabilidade não puder ser encontrado durante o período de escalabilidade.
## Registro em log para o Aurora Serverless v1
Por padrão, logs de erros para o Aurora Serverless v1 são ativados e carregados automaticamente no Amazon CloudWatch. Você também pode fazer com que seu cluster de banco de dados do Aurora Serverless v1 carregue logs específicos do mecanismo de banco de dados do Aurora para o CloudWatch. Para fazer isso, habilite os parâmetros de configuração em seu grupo de parâmetros do seu cluster de banco de dados personalizado. Depois, seu cluster de banco de dados do Aurora Serverless v1 carrega todos os logs disponíveis para o Amazon CloudWatch. Nesse momento, é possível usar o CloudWatch para analisar os dados de log, criar alarmes e visualizar métricas.
No caso do Aurora MySQL, a tabela a seguir mostra os logs que você pode habilitar. Quando habilitados, é feito upload deles automaticamente do cluster de banco de dados do Aurora Serverless v1 para o Amazon CloudWatch.
| Log do Aurora MySQL | Descrição |
| --- | --- |
| `general_log` | Cria o log geral. Defina como 1 para ativar. O padrão é desativado (0). |
| `log_queries_not_using_indexes` | Registra todas as consultas no log de consultas lentas que não usam um índice. O padrão é desativado (0). Defina como 1 para ativar esse log. |
| `long_query_time` | Impede que consultas em execução rápida sejam registradas no log de consultas lentas. Pode ser definido como um float entre 0 e 3.1536.000. O padrão é 0 (não ativo). |
| `server_audit_events` | A lista de eventos a serem capturados nos logs. Os valores compatíveis são `CONNECT`, `QUERY`, `QUERY_DCL`, `QUERY_DDL`, `QUERY_DML` e `TABLE`. |
| `server_audit_logging` | Defina como 1 para ativar o log de auditoria do servidor. Se você ativar isso, você poderá especificar os eventos de auditoria a serem enviados, CloudWatch listando-os no `server_audit_events` parâmetro. |
| `slow_query_log` | Cria um log de consulta lento. Defina como 1 para ativar o log de consulta lenta. O padrão é desativado (0). |
Para obter mais informações, consulte [Como utilizar a auditoria avançada em um cluster de banco de dados do Amazon Aurora MySQL](AuroraMySQL.Auditing.md).
No caso do Aurora PostgreSQL, a tabela a seguir mostra os logs que você pode habilitar. Quando habilitados, é feito upload deles automaticamente do cluster de banco de dados do Aurora Serverless v1 para o Amazon CloudWatch com os logs de erro regulares.
| Log do Aurora PostgreSQL | Descrição |
| --- | --- |
| `log_connections` | Ativado por padrão e não pode ser alterado. Ele registra detalhes para todas as novas conexões de clientes. |
| `log_disconnections` | Ativado por padrão e não pode ser alterado. Registra todas as desconexões de clientes. |
| `log_hostname` | Desativado por padrão e não pode ser alterado. Nomes de host não são registrados no log. |
| `log_lock_waits` | O padrão é 0 (desativado). Defina como 1 para registrar esperas por bloqueio. |
| `log_min_duration_statement` | A duração mínima (em milissegundos) para que uma instrução seja executada antes de ser registrada. |
| `log_min_messages` | Define os níveis de mensagem registrados. Os valores compatíveis são `debug5`, `debug4`, `debug3`, `debug2`, `debug1`, `info`, `notice`, `warning`, `error`, `log`, `fatal`, `panic`. Para registrar dados de performance no log do `postgres`, defina o valor como `debug1`. |
| `log_temp_files` | Registra o uso de arquivos temporários que estão acima dos kilobytes (kB) especificados. |
| `log_statement` | Controla as instruções SQL específicas que são registradas. Os valores compatíveis são `none`, `ddl`, `mod` e `all`. O padrão é `none`. |
Depois de ativar os logs para Aurora MySQL ou Aurora PostgreSQL para o cluster de banco de dados do Aurora Serverless v1, você pode visualizá-los no CloudWatch.
### Visualizar logs do Aurora Serverless v1 com o Amazon CloudWatch
Aurora Serverless v1O carrega automaticamente (“publica”) no Amazon CloudWatch todos os logs que estão ativados em seu grupo de parâmetros de cluster de banco de dados personalizado. Você não precisa escolher ou especificar os tipos de log. O upload de logs começa assim que você habilita o parâmetro de configuração de log. Se, mais tarde, você desabilitar o parâmetro de log, os uploads serão interrompidos. No entanto, todos os logs que já foram publicados no CloudWatch permanecem até que você os exclua.
Para mais informações sobre como usar o CloudWatch com os logs do Aurora MySQL, consulte [Monitorar eventos de log no Amazon CloudWatch](AuroraMySQL.Integrating.CloudWatch.md#AuroraMySQL.Integrating.CloudWatch.Monitor).
Para ter mais informações sobre CloudWatch e Aurora PostgreSQL, consulte [Publicar logs do Aurora PostgreSQL no Amazon CloudWatch Logs](AuroraPostgreSQL.CloudWatch.md).
**Para visualizar logs do cluster de banco de dados do Aurora Serverless v1**
1. Abra o console do CloudWatch, em [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/).
1. Escolha a Região da AWS.
1. Escolha **Grupos de logs**.
1. Escolha o log do cluster de banco de dados do Aurora Serverless v1 na lista. Para logs de erros, o padrão de nomenclatura é o seguinte.
```
/aws/rds/cluster/cluster-name/error
```
Por exemplo, no snapshot a seguir, você pode encontrar listagens para logs publicados para um cluster de banco de dados do Aurora Serverless v1 para Aurora PostgreSQL denominado `western-sles`. Você também pode encontrar várias listas para cluster de banco de dados do Aurora Serverless v1 para Aurora MySQL, `west-coast-sles`. Escolha o log de interesse para começar a explorar seu conteúdo.
![\[Logs publicados no CloudWatch Logs para clusters de banco de dados do Aurora Serverless v1 para Aurora MySQL e Aurora PostgreSQL\]](http://docs.aws.amazon.com/pt_br/AmazonRDS/latest/AuroraUserGuide/images/aurora-serverless-logs-in-cloudwatch.png)
## Aurora Serverless v1 e manutenção
A manutenção do cluster de banco de dados do Aurora Serverless v1, como a aplicação dos recursos, das correções e das atualizações de segurança mais recentes, é realizada automaticamente para você. O Aurora Serverless v1 tem uma janela de manutenção que você pode visualizar no Console de gerenciamento da AWS em **Manutenção e backups** para seu cluster de banco de dados do Aurora Serverless v1. É possível encontrar a data e a hora em que a manutenção pode ser realizada e se alguma manutenção está pendente para o cluster de banco de dados do Aurora Serverless v1, conforme mostrado na figura a seguir.
![\[Janela de manutenção para um exemplo de cluster de banco de dados do Aurora Serverless v1, sem manutenção pendente\]](http://docs.aws.amazon.com/pt_br/AmazonRDS/latest/AuroraUserGuide/images/aurora-serverless-maintenance-window.png)
Você pode definir a janela de manutenção ao criar o cluster de banco de dados do Aurora Serverless v1 e pode modificá-la posteriormente. Para ter mais informações, consulte [Ajustar a janela de manutenção do cluster de banco de dados preferencial](USER_UpgradeDBInstance.Maintenance.md#AdjustingTheMaintenanceWindow.Aurora).
As janelas de manutenção são usadas para atualizações programadas de versões principais. Atualizações de versões secundárias e patches são aplicados imediatamente durante o ajuste de escala. O ajuste de escala ocorre de acordo com a configuração de `TimeoutAction`:
+ `ForceApplyCapacityChange`: a alteração é aplicada imediatamente.
+ `RollbackCapacityChange`: o Aurora atualizará o cluster à força após três dias a partir da primeira tentativa.
Tal como acontece com qualquer alteração que seja forçada sem um ponto de escala apropriado, isso pode interromper sua workload.
Sempre que possível, o Aurora Serverless v1 realiza a manutenção sem causar disrupções. Quando a manutenção é necessária, o cluster de banco de dados do Aurora Serverless v1 dimensiona sua capacidade para lidar com as operações necessárias. Antes de escalar, o Aurora Serverless v1 procura um ponto de escalabilidade. Se necessário, isso será realizado por até três dias.
No fim de cada dia em que o Aurora Serverless v1 não consegue encontrar um ponto de escalabilidade, ele cria um evento de cluster. Esse evento notifica você sobre a manutenção pendente e a necessidade de dimensionar para executar a manutenção. A notificação inclui a data em que o Aurora Serverless v1 pode forçar o cluster de banco de dados a escalar.
Para obter mais informações, consulte [Ação de tempo limite para alterações na capacidade](#aurora-serverless.how-it-works.timeout-action).
## Aurora Serverless v1 e failover
Se a instância de banco de dados de um cluster de banco de dados do Aurora Serverless v1 ficar indisponível ou a zona de disponibilidade (AZ) em que ela está estiver com falha, o Aurora recriará a instância de banco de dados em uma AZ diferente. No entanto, o cluster do Aurora Serverless v1 não é um cluster multi-AZ. O motivo disso é que ele consiste em uma única instância de banco de dados em uma única AZ. Dessa forma, esse mecanismo de failover leva mais tempo do que um cluster do Aurora com instâncias do Aurora Serverless v2 ou provisionadas. O tempo de failover do Aurora Serverless v1 é indefinido no momento, porque depende da demanda e da disponibilidade da capacidade em outras AZs na Região da AWS indicada.
Como o Aurora separa a capacidade computacional e o armazenamento, o volume de armazenamento do cluster é distribuído em várias AZs. Seus dados permanecem disponíveis mesmo que as interrupções afetem a instância de banco de dados ou a AZ associada.
## Aurora Serverless v1 e snapshots
O volume do cluster de um cluster do Aurora Serverless v1 é sempre criptografado. É possível escolher a chave de criptografia, mas não é possível desabilitar a criptografia. Para copiar ou compartilhar um snapshot de um cluster do Aurora Serverless v1, criptografe o snapshot usando a sua própria AWS KMS key. Para ter mais informações, consulte [Cópia de snapshot de cluster de banco de dados](aurora-copy-snapshot.md). Para saber mais sobre criptografia e o Amazon Aurora, consulte [Criptografar um cluster de banco de dados do Amazon Aurora](Overview.Encryption.md#Overview.Encryption.Enabling)
# Criar um cluster de banco de dados do Aurora Serverless v1
**Importante**
A AWS anunciou [ a data de fim da vida útil do Aurora Serverless v1: 31 de março de 2025](https://repost.aws/questions/QUhcMVoChXRm2HLi8F-yih1g/announcement-support-for-aurora-s/announcement-support-for-aurora-serverless-v1-ending-soon). Todos os clusters do Aurora Serverless v1 que não forem migrados até 31 de março de 2025 serão migrados para o Aurora Serverless v2 durante a janela de manutenção. Se a atualização falhar, durante a janela de manutenção do Amazon Aurora converterá o cluster do Sem Servidor v1 em um cluster provisionado com a versão de mecanismo equivalente. Se aplicável, o Amazon Aurora inscreverá o cluster provisionado convertido no Exporte estendido do Amazon RDS. Para ter mais informações, consulte [Suporte estendido do Amazon RDS com Amazon Aurora](extended-support.md).
O procedimento a seguir cria um cluster do Aurora Serverless v1 sem nenhum dos objetos nem dados do esquema. Se você deseja criar um cluster do Aurora Serverless v1 seja uma duplicata de um cluster provisionado existente ou do Aurora Serverless v1, realize uma operação de restauração ou clonagem de snapshots. Para obter esses detalhes, consulte [Restauração de um snapshot de um cluster de banco de dados](aurora-restore-snapshot.md) e [Clonar um volume para um cluster de banco de dados do Amazon Aurora](Aurora.Managing.Clone.md). Não é possível converter um cluster provisionado existente em Aurora Serverless v1. Também não é possível converter um cluster do Aurora Serverless v1 em um cluster provisionado.
Ao criar um cluster de banco de dados do Aurora Serverless v1, configure as capacidades mínima e máxima para o cluster. Uma unidade de capacidade é equivalente a uma configuração específica de computação e memória. O Aurora Serverless v1 cria regras de escalabilidade de limites para utilização de CPU, conexões e memória disponível e escala perfeitamente para uma série de unidades de capacidade, conforme o necessário às suas aplicações. Para ter mais informações, consulte [Aurora Serverless v1Arquitetura do](aurora-serverless-v1.how-it-works.md#aurora-serverless.architecture).
É possível definir os seguintes valores específicos para seu cluster de banco de dados do Aurora Serverless v1:
+ **Minimum Aurora capacity unit** (Unidade de capacidade mínima do Aurora): o Aurora Serverless v1 pode reduzir a capacidade até essa unidade de capacidade.
+ **Maximum Aurora capacity unit** (Unidade de capacidade máxima do Aurora): o Aurora Serverless v1 pode aumentar a capacidade até essa unidade de capacidade.
Também é possível escolher as seguintes opções opcionais de configuração de escalabilidade:
+ **Force scaling the capacity to the specified values when the timeout is reached** (Forçar escalabilidade da capacidade para os valores especificados quando o tempo limite for atingido) é possível escolher essa configuração se quiser que o Aurora Serverless v1 force o Aurora Serverless v1 a escalar, mesmo que não consiga encontrar um ponto de escalabilidade antes do tempo limite. Se você quiser que o Aurora Serverless v1 cancele as alterações de capacidade se não conseguir encontrar um ponto de escalabilidade, não escolha essa definição. Para ter mais informações, consulte [Ação de tempo limite para alterações na capacidade](aurora-serverless-v1.how-it-works.md#aurora-serverless.how-it-works.timeout-action).
+ **Pause compute capacity after consecutive minutes of inactivity** (Pausar a capacidade computacional após minutos consecutivos de inatividade): é possível escolher essa configuração se você quiser que o Aurora Serverless v1 escale para zero quando não houver atividade no cluster de banco de dados por um período especificado. Com essa configuração ativada, o cluster de banco de dados do Aurora Serverless v1 retoma o processamento automaticamente e escala para a capacidade necessária para lidar com a workload quando o tráfego do banco de dados for retomado. Para saber mais, consulte [Pausa e retomada para o Aurora Serverless v1](aurora-serverless-v1.how-it-works.md#aurora-serverless.how-it-works.pause-resume).
Antes de criar um cluster de banco de dados do Aurora Serverless v1, é necessária uma conta da AWS. Também é necessário concluir as tarefas de configuração para trabalhar com o Amazon Aurora. Para ter mais informações, consulte [Configuração de seu ambiente para Amazon Aurora](CHAP_SettingUp_Aurora.md). Também é necessário concluir outras etapas preliminares para criar qualquer cluster de bancos de dados Aurora. Para saber mais, consulte [Criar um cluster de bancos de dados do Amazon Aurora](Aurora.CreateInstance.md).
O Aurora Serverless v1 está disponível em determinadas Regiões da AWS e somente para versões específicas do Aurora MySQL e do Aurora PostgreSQL. Para ter mais informações, consulte [Aurora Serverless v1 da](Concepts.Aurora_Fea_Regions_DB-eng.Feature.ServerlessV1.md).
**nota**
O volume do cluster de um cluster do Aurora Serverless v1 é sempre criptografado. Ao criar seu cluster de banco de dados do Aurora Serverless v1, não é possível desativar a criptografia, mas pode optar por usar sua própria chave de criptografia. Com o Aurora Serverless v2, você pode escolher se deseja criptografar o volume do cluster.
É possível criar um novo cluster de banco de dados do Aurora Serverless v1 com a AWS CLI ou a API do RDS.
**nota**
Se você receber a seguinte mensagem de erro ao tentar criar seu cluster, sua conta precisará de permissões adicionais.
`Unable to create the resource. Verify that you have permission to create service linked role. Otherwise wait and try again later.`
Consulte [Usar funções vinculadas ao serviço do Amazon Aurora](UsingWithRDS.IAM.ServiceLinkedRoles.md) para obter mais informações.
Você não pode se conectar diretamente à instância de banco de dados em seu cluster de banco de dados do Aurora Serverless v1. Para se conectar a um cluster de banco de dados do Aurora Serverless v1, use o endpoint do banco de dados. Você pode encontrar o endpoint do seu cluster de banco de dados do Aurora Serverless v1 na guia **Connectivity & security (Conectividade e segurança)** do cluster no Console de gerenciamento da AWS. Para obter mais informações, consulte [Como conectar-se a um cluster de bancos de dados Amazon Aurora](Aurora.Connecting.md).
## AWS CLI
Para criar um novo cluster de banco de dados do Aurora Serverless v1 com a AWS CLI, execute o comando [create-db-cluster](https://docs.aws.amazon.com/cli/latest/reference/rds/create-db-cluster.html) e especifique `serverless` na opção `--engine-mode`.
Opcionalmente, você pode especificar a opção `--scaling-configuration` para configurar a capacidade mínima, a capacidade máxima e a pausa automática quando não houver conexões.
Os exemplos de comando a seguir criam um novo cluster de banco de dados Serverless configurando a opção `--engine-mode` como `serverless`. O exemplo também especifica valores para a opção `--scaling-configuration`.
### Exemplo de Aurora MySQL
O comando a seguir cria um cluster de banco de dados sem servidor compatível com o Aurora MySQL. Os valores de capacidade válidos para Aurora MySQL são `1`, `2`, `4`, `8`, `16`, `32`, `64`, `128` e `256`.
Para Linux, macOS ou Unix:
```
aws rds create-db-cluster --db-cluster-identifier sample-cluster \
--engine aurora-mysql --engine-version 5.7.mysql_aurora.2.11.4 \
--engine-mode serverless \
--scaling-configuration MinCapacity=4,MaxCapacity=32,SecondsUntilAutoPause=1000,AutoPause=true \
--master-username username --master-user-password password
```
Para Windows:
```
aws rds create-db-cluster --db-cluster-identifier sample-cluster ^
--engine aurora-mysql --engine-version 5.7.mysql_aurora.2.11.4 ^
--engine-mode serverless ^
--scaling-configuration MinCapacity=4,MaxCapacity=32,SecondsUntilAutoPause=1000,AutoPause=true ^
--master-username username --master-user-password password
```
### Exemplo de Aurora PostgreSQL
O comando a seguir cria um cluster de banco de dados sem servidor compatível com o PostgreSQL 13.9. Os valores de capacidade válidos para o Aurora PostgreSQL são `2`, `4`, `8`, `16`, `32`, `64`, `192` e `384`.
Para Linux, macOS ou Unix:
```
aws rds create-db-cluster --db-cluster-identifier sample-cluster \
--engine aurora-postgresql --engine-version 13.9 \
--engine-mode serverless \
--scaling-configuration MinCapacity=8,MaxCapacity=64,SecondsUntilAutoPause=1000,AutoPause=true \
--master-username username --master-user-password password
```
Para Windows:
```
aws rds create-db-cluster --db-cluster-identifier sample-cluster ^
--engine aurora-postgresql --engine-version 13.9 ^
--engine-mode serverless ^
--scaling-configuration MinCapacity=8,MaxCapacity=64,SecondsUntilAutoPause=1000,AutoPause=true ^
--master-username username --master-user-password password
```
## API do RDS
Para criar um cluster de banco de dados do Aurora Serverless v1 com a API do RDS, execute a operação [CreateDBCluster](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_CreateDBCluster.html) e especifique `serverless` para o parâmetro `EngineMode`.
Opcionalmente, você pode especificar o parâmetro `ScalingConfiguration` para configurar a capacidade mínima, a capacidade máxima e a pausa automática quando não houver conexões. Entre os valores de capacidade válidos estão os seguintes:
+ Aurora MySQL: `1`, `2`, `4`, `8`, `16`, `32`, `64`, `128` e `256`.
+ Aurora PostgreSQL: `2`, `4`, `8`, `16`, `32`, `64`, `192` e `384`.
# Restaurar um cluster de banco de dados do Aurora Serverless v1
**Importante**
A AWS anunciou [ a data de fim da vida útil do Aurora Serverless v1: 31 de março de 2025](https://repost.aws/questions/QUhcMVoChXRm2HLi8F-yih1g/announcement-support-for-aurora-s/announcement-support-for-aurora-serverless-v1-ending-soon). Todos os clusters do Aurora Serverless v1 que não forem migrados até 31 de março de 2025 serão migrados para o Aurora Serverless v2 durante a janela de manutenção. Se a atualização falhar, durante a janela de manutenção do Amazon Aurora converterá o cluster do Sem Servidor v1 em um cluster provisionado com a versão de mecanismo equivalente. Se aplicável, o Amazon Aurora inscreverá o cluster provisionado convertido no Exporte estendido do Amazon RDS. Para ter mais informações, consulte [Suporte estendido do Amazon RDS com Amazon Aurora](extended-support.md).
É possível configurar um cluster de banco de dados do Aurora Serverless v1 ao restaurar um snapshot de cluster de banco de dados provisionado com a AWS CLI ou a API do RDS.
Ao restaurar um snapshot em um cluster de banco de dados do Aurora Serverless v1, é possível definir os seguintes valores específicos:
+ **Minimum Aurora capacity unit** (Unidade de capacidade mínima do Aurora): o Aurora Serverless v1 pode reduzir a capacidade até essa unidade de capacidade.
+ **Maximum Aurora capacity unit** (Unidade de capacidade máxima do Aurora): o Aurora Serverless v1 pode aumentar a capacidade até essa unidade de capacidade.
+ **Timeout action** (Ação de tempo limite): a ação a ser executada quando uma modificação de capacidade expira porque não consegue encontrar um ponto de escalabilidade. Aurora Serverless v1 O cluster de banco de dados poderá forçar o cluster de banco de dados para as novas configurações de capacidade se definir a opção **Force scaling the capacity to the specified values...** (Forçar escalabilidade da capacidade para os valores especificados...). Ou ele poderá reverter a alteração de capacidade para cancelá-la se você não escolher a opção. Para obter mais informações, consulte [Ação de tempo limite para alterações na capacidade](aurora-serverless-v1.how-it-works.md#aurora-serverless.how-it-works.timeout-action).
+ **Pause after inactivity (Pausar depois de inatividade)** – a quantidade de tempo sem tráfego no banco de dados que determina o redimensionamento da capacidade de processamento para zero. Quando o tráfego no banco de dados é retomado, o Aurora retoma automaticamente a capacidade de processamento e escala para tratar o tráfego.
Para obter mais informações gerais sobre como restaurar um cluster de banco de dados a partir de um snapshot, consulte [Restauração de um snapshot de um cluster de banco de dados](aurora-restore-snapshot.md).
## AWS CLI
É possível configurar um cluster de banco de dados do Aurora Serverless ao restaurar um snapshot de cluster de banco de dados provisionado com o Console de gerenciamento da AWS, a AWS CLI ou a API do RDS.
Ao restaurar um snapshot em um cluster de banco de dados do Aurora Serverless, é possível definir os seguintes valores específicos:
+ **Minimum Aurora capacity unit** (Unidade de capacidade mínima do Aurora): o Aurora Serverless pode reduzir a capacidade até essa unidade de capacidade.
+ **Maximum Aurora capacity unit** (Unidade de capacidade máxima do Aurora): o Aurora Serverless pode aumentar a capacidade até essa unidade de capacidade.
+ **Timeout action** (Ação de tempo limite): a ação a ser executada quando uma modificação de capacidade expira porque não consegue encontrar um ponto de escalabilidade. Aurora Serverless v1 O cluster de banco de dados poderá forçar o cluster de banco de dados para as novas configurações de capacidade se definir a opção **Force scaling the capacity to the specified values...** (Forçar escalabilidade da capacidade para os valores especificados...). Ou ele poderá reverter a alteração de capacidade para cancelá-la se você não escolher a opção. Para obter mais informações, consulte [Ação de tempo limite para alterações na capacidade](aurora-serverless-v1.how-it-works.md#aurora-serverless.how-it-works.timeout-action).
+ **Pause after inactivity (Pausar depois de inatividade)** – a quantidade de tempo sem tráfego no banco de dados que determina o redimensionamento da capacidade de processamento para zero. Quando o tráfego no banco de dados é retomado, o Aurora retoma automaticamente a capacidade de processamento e escala para tratar o tráfego.
**nota**
A versão do snapshot do cluster de banco de dados deve ser compatível com o Aurora Serverless v1. Para obter a lista de versões compatíveis, consulte [Aurora Serverless v1 da](Concepts.Aurora_Fea_Regions_DB-eng.Feature.ServerlessV1.md).
Para restaurar um snapshot para um cluster do Aurora Serverless v1 com compatibilidade com o MySQL 5.7, inclua os seguintes parâmetros adicionais:
+ `--engine aurora-mysql`
+ `--engine-version 5.7`
Os parâmetros `--engine` e `--engine-version` permitem que você crie um cluster do Aurora Serverless v1 compatível com MySQL 5.7 a partir de um snapshot do Aurora compatível com o MySQL 5.6 ou do Aurora Serverless v1 . O exemplo a seguir restaura um snapshot de um cluster compatível com MySQL 5.6 chamado *mydbclustersnapshot* para um cluster Aurora Serverless v1 compatível com MySQL 5.7 chamado *mynewdbcluster*.
Para Linux, macOS ou Unix:
```
aws rds restore-db-cluster-from-snapshot \
--db-cluster-identifier mynewdbcluster \
--snapshot-identifier mydbclustersnapshot \
--engine-mode serverless \
--engine aurora-mysql \
--engine-version 5.7
```
Para Windows:
```
aws rds restore-db-cluster-from-snapshot ^
--db-instance-identifier mynewdbcluster ^
--db-snapshot-identifier mydbclustersnapshot ^
--engine aurora-mysql ^
--engine-version 5.7
```
Opcionalmente, você pode especificar a opção `--scaling-configuration` para configurar a capacidade mínima, a capacidade máxima e a pausa automática quando não houver conexões. Entre os valores de capacidade válidos estão os seguintes:
+ Aurora MySQL: `1`, `2`, `4`, `8`, `16`, `32`, `64`, `128` e `256`.
+ Aurora PostgreSQL: `2`, `4`, `8`, `16`, `32`, `64`, `192` e `384`.
No exemplo a seguir, você restaura de um snapshot de cluster de banco de dados criado anteriormente chamado *mydbclustersnapshot* para um novo cluster de banco de dados chamado *mynewdbcluster*. Você define o `--scaling-configuration` para que o novo cluster de banco de dados do Aurora Serverless v1 possa escalar de 8 ACUs para 64 ACUs (unidades de capacidade do Aurora) conforme necessário para processar a workload. Após a conclusão do processamento e após 1000 segundos sem nenhuma conexão compatível, o cluster é encerrado até que as solicitações de conexão peçam para reiniciar.
Para Linux, macOS ou Unix:
```
aws rds restore-db-cluster-from-snapshot \
--db-cluster-identifier mynewdbcluster \
--snapshot-identifier mydbclustersnapshot \
--engine-mode serverless --scaling-configuration MinCapacity=8,MaxCapacity=64,TimeoutAction='ForceApplyCapacityChange',SecondsUntilAutoPause=1000,AutoPause=true
```
Para Windows:
```
aws rds restore-db-cluster-from-snapshot ^
--db-instance-identifier mynewdbcluster ^
--db-snapshot-identifier mydbclustersnapshot ^
--engine-mode serverless --scaling-configuration MinCapacity=8,MaxCapacity=64,TimeoutAction='ForceApplyCapacityChange',SecondsUntilAutoPause=1000,AutoPause=true
```
## API do RDS
Para configurar um cluster de banco de dados do Aurora Serverless v1 ao restaurar um cluster de banco de dados usando a API do RDS, execute a operação [RestoreDBClusterFromSnapshot](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_RestoreDBClusterFromSnapshot.html) e especifique `serverless` no parâmetro `EngineMode`.
Opcionalmente, você pode especificar o parâmetro `ScalingConfiguration` para configurar a capacidade mínima, a capacidade máxima e a pausa automática quando não houver conexões. Entre os valores de capacidade válidos estão os seguintes:
+ Aurora MySQL: `1`, `2`, `4`, `8`, `16`, `32`, `64`, `128` e `256`.
+ Aurora PostgreSQL: `2`, `4`, `8`, `16`, `32`, `64`, `192` e `384`.
# Modificar um cluster de banco de dados do Aurora Serverless v1
**Importante**
A AWS anunciou [ a data de fim da vida útil do Aurora Serverless v1: 31 de março de 2025](https://repost.aws/questions/QUhcMVoChXRm2HLi8F-yih1g/announcement-support-for-aurora-s/announcement-support-for-aurora-serverless-v1-ending-soon). Todos os clusters do Aurora Serverless v1 que não forem migrados até 31 de março de 2025 serão migrados para o Aurora Serverless v2 durante a janela de manutenção. Se a atualização falhar, durante a janela de manutenção do Amazon Aurora converterá o cluster do Sem Servidor v1 em um cluster provisionado com a versão de mecanismo equivalente. Se aplicável, o Amazon Aurora inscreverá o cluster provisionado convertido no Suporte estendido do Amazon RDS. Para obter mais informações, consulte [Suporte estendido do Amazon RDS com Amazon Aurora](extended-support.md).
Depois de configurar um cluster de banco de dados do Aurora Serverless v1, é possível modificar determinadas propriedades com o Console de gerenciamento da AWS, a AWS CLI ou a API do RDS. A maioria das propriedades que você pode modificar é a mesma de outros tipos de clusters do Aurora.
As alterações mais relevantes do Aurora Serverless v1 são as seguintes:
+ [Modificar a configuração de ajuste de escala](#aurora-serverless.modifying.scaling)
+ [Atualizar a versão principal](#aurora-serverless.modifying.upgrade)
+ [Conversão de Aurora Serverless v1 em provisionado](#aurora-serverless.modifying.convert)
## Modificar a configuração de ajuste de escala de um cluster de banco de dados do Aurora Serverless v1
As capacidades mínima e máxima podem ser definidas para o cluster de banco de dados. Cada unidade de capacidade é equivalente a uma configuração específica de computação e de memória. O Aurora Serverless cria automaticamente regras de escalabilidade de limites para utilização de CPU, conexões e memória disponível. Também é possível definir se o Aurora Serverless pausa o banco de dados quando não há nenhuma atividade e se retoma quando a atividade começa novamente.
É possível definir os seguintes valores específicos para a configuração de escalabilidade:
+ **Minimum Aurora capacity unit** (Unidade de capacidade mínima do Aurora): o Aurora Serverless pode reduzir a capacidade até essa unidade de capacidade.
+ **Maximum Aurora capacity unit** (Unidade de capacidade máxima do Aurora): o Aurora Serverless pode aumentar a capacidade até essa unidade de capacidade.
+ **Autoscaling timeout and action** (Tempo limite e ação de autoescalabilidade): esta seção especifica quanto tempo o Aurora Serverless aguarda até encontrar um ponto de escalabilidade antes de expirar. Também especifica a ação a ser executada quando uma alteração de capacidade expira, pois não consegue encontrar um ponto de escalabilidade. O Aurora pode forçar a alteração na capacidade para definir a capacidade para o valor especificado assim que possível. Ou, pode reverter a alteração na capacidade para cancelá-la. Para obter mais informações, consulte [Ação de tempo limite para alterações na capacidade](aurora-serverless-v1.how-it-works.md#aurora-serverless.how-it-works.timeout-action).
+ **Pausa após a inatividade**: use a configuração opcional **Ajustar a escala da capacidade para 0 ACU quando o cluster estiver ocioso** para ajustar a escala do banco de dados para zero capacidade de processamento enquanto ele estiver inativo. Quando o tráfego no banco de dados é retomado, o Aurora retoma automaticamente a capacidade de processamento e escala para tratar o tráfego.
**nota**
Quando você modifica o intervalo de capacidade de um cluster de banco de dados do Aurora Serverless, a alteração ocorre imediatamente, independentemente de você optar por aplicá-la imediatamente ou durante a próxima janela de manutenção programada.
### Console
Você pode modificar a configuração de escalabilidade de um cluster de bancos de dados Aurora com o Console de gerenciamento da AWS.
**Como modificar um cluster de banco de dados do Aurora Serverless v1**
1. Abra o console do Amazon RDS em [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/).
1. No painel de navegação, escolha **Databases (Bancos de dados)**.
1. Escolha o cluster de banco de dados do Aurora Serverless v1 que você deseja modificar.
1. Em **Actions (Ações)**, escolha **Modify cluster (Modificar cluster)**.
1. Na seção **Capacity settings (Configurações da capacidade)**, modifique a configuração de escalabilidade.
1. Escolha **Continuar**.
1. Na página **Modificar cluster de banco de dados**, revise suas modificações e escolha quando aplicá-las.
1. Escolha **Modificar Cluster**.
### AWS CLI
Para modificar a configuração de escalabilidade do cluster de banco de dados do Aurora Serverless v1 usando a AWS CLI, execute o comando [modify-db-cluster](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/rds/modify-db-cluster.html) da AWS CLI. Especifique a opção `--scaling-configuration` para configurar a capacidade mínima, a capacidade máxima e a pausa automática quando não houver conexões. Entre os valores de capacidade válidos estão os seguintes:
+ Aurora MySQL: `1`, `2`, `4`, `8`, `16`, `32`, `64`, `128` e `256`.
+ Aurora PostgreSQL: `2`, `4`, `8`, `16`, `32`, `64`, `192` e `384`.
Neste exemplo, modifique a configuração de escalabilidade de um cluster de banco de dados do Aurora Serverless v1 chamado *sample-cluster*.
Para Linux, macOS ou Unix:
```
aws rds modify-db-cluster \
--db-cluster-identifier sample-cluster \
--scaling-configuration MinCapacity=8,MaxCapacity=64,SecondsUntilAutoPause=500,TimeoutAction='ForceApplyCapacityChange',AutoPause=true
```
Para Windows:
```
aws rds modify-db-cluster ^
--db-cluster-identifier sample-cluster ^
--scaling-configuration MinCapacity=8,MaxCapacity=64,SecondsUntilAutoPause=500,TimeoutAction='ForceApplyCapacityChange',AutoPause=true
```
### API do RDS
É possível modificar a configuração de escalabilidade de um cluster de bancos de dados Aurora com a operação da API [ModifyDBCluster](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyDBCluster.html). Especifique o parâmetro `ScalingConfiguration` para configurar a capacidade mínima, a capacidade máxima e a pausa automática quando não houver conexões. Entre os valores de capacidade válidos estão os seguintes:
+ Aurora MySQL: `1`, `2`, `4`, `8`, `16`, `32`, `64`, `128` e `256`.
+ Aurora PostgreSQL: `2`, `4`, `8`, `16`, `32`, `64`, `192` e `384`.
## Atualizar a versão principal de um cluster de banco de dados do Aurora Serverless v1
**Importante**
A AWS anunciou [ a data de fim da vida útil do Aurora Serverless v1: 31 de março de 2025](https://repost.aws/questions/QUhcMVoChXRm2HLi8F-yih1g/announcement-support-for-aurora-s/announcement-support-for-aurora-serverless-v1-ending-soon). Todos os clusters do Aurora Serverless v1 que não forem migrados até 31 de março de 2025 serão migrados para o Aurora Serverless v2 durante a janela de manutenção. Se a atualização falhar, durante a janela de manutenção do Amazon Aurora converterá o cluster do Sem Servidor v1 em um cluster provisionado com a versão de mecanismo equivalente. Se aplicável, o Amazon Aurora inscreverá o cluster provisionado convertido no Suporte estendido do Amazon RDS. Para obter mais informações, consulte [Suporte estendido do Amazon RDS com Amazon Aurora](extended-support.md).
Você pode fazer upgrade da versão principal de um cluster de banco de dados do Aurora Serverless v1 compatível com o PostgreSQL 11 para uma versão correspondente compatível com o PostgreSQL 13.
### Console
Você pode realizar uma atualização no local de um cluster de banco de dados do Aurora Serverless v1 usando o Console de gerenciamento da AWS.
**Como atualizar um cluster de banco de dados do Aurora Serverless v1**
1. Abra o console do Amazon RDS em [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/).
1. No painel de navegação, escolha **Databases (Bancos de dados)**.
1. Selecione o cluster de banco de dados do Aurora Serverless v1 que você deseja atualizar.
1. Em **Actions (Ações)**, escolha **Modify cluster (Modificar cluster)**.
1. Em **Versão**, escolha uma versão 13 do Aurora PostgreSQL.
O exemplo a seguir mostra uma atualização no local do Aurora PostgreSQL 11.16 para 13.9.
![\[Fazer upgrade de um cluster de banco de dados do Aurora Serverless v1 usando o console\]](http://docs.aws.amazon.com/pt_br/AmazonRDS/latest/AuroraUserGuide/images/sv1-upgrade-apg11-to-13.png)
Se você realizar uma atualização de versão principal, deixe todas as outras propriedades iguais. Para alterar qualquer uma das outras propriedades, realize outra operação **Modificar** após o término da atualização.
1. Escolha **Continuar**.
1. Na página **Modificar cluster de banco de dados**, revise suas modificações e escolha quando aplicá-las.
1. Escolha **Modificar Cluster**.
### AWS CLI
Para realizar uma atualização no local de um cluster de banco de dados do Aurora Serverless v1 compatível com o PostgreSQL 11 para um compatível com o PostgreSQL 13, especifique o parâmetro `--engine-version` com um número de versão do Aurora PostgreSQL versão 13 compatível com o Aurora Serverless v1. Inclua também o parâmetro `--allow-major-version-upgrade`.
Neste exemplo, modifique a versão principal de um cluster de banco de dados do Aurora Serverless v1 compatível com o PostgreSQL 11 denominado `sample-cluster`. Com esse procedimento, é realizado uma atualização no local para um cluster de banco de dados do Aurora Serverless v1 compatível com o PostgreSQL 13.
```
aws rds modify-db-cluster \
--db-cluster-identifier sample-cluster \
--engine-version 13.serverless_12 \
--allow-major-version-upgrade
```
Para Windows:
```
aws rds modify-db-cluster ^
--db-cluster-identifier sample-cluster ^
--engine-version 13.serverless_12 ^
--allow-major-version-upgrade
```
### API do RDS
Para realizar uma atualização no local de um cluster de banco de dados do Aurora Serverless v1 compatível com o PostgreSQL 11 para um compatível com o PostgreSQL 13, especifique o parâmetro `EngineVersion` com um número de versão do Aurora PostgreSQL versão 13 compatível com o Aurora Serverless v1. Inclua também o parâmetro `AllowMajorVersionUpgrade`.
## Realizar a conversão de um cluster de banco de dados do Aurora Serverless v1 provisionado
É possível converter um cluster de banco de dados do Aurora Serverless v1 em um cluster de banco de dados provisionado. Para realizar a conversão, use a AWS CLI ou a API do Amazon RES para alterar a classe da instância de banco de dados para **Provisionada**. Use as etapas abaixo para modificar a classe de instância de banco de dados.
O exemplo a seguir demonstra como usar a AWS CLI para converter um cluster de banco de dados do Aurora Serverless v1 em um cluster provisionado.
### AWS CLI
Para converter um cluster de banco de dados do Aurora Serverless v1 em um cluster provisionado, execute o comando [modify-db-cluster](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-cluster.html) da AWS CLI.
Os seguintes parâmetros são obrigatórios:
+ `--db-cluster-identifier`: o cluster de banco de dados do Aurora Serverless v1 que você está convertendo em provisionado.
+ `--engine-mode`: use o valor `provisioned`.
+ `--allow-engine-mode-change`
+ `--db-cluster-instance-class`: escolha a classe da instância de banco de dados para o cluster de banco de dados provisionado com base na capacidade do cluster de banco de dados do Aurora Serverless v1.
Neste exemplo, você converte um cluster de banco de dados do Aurora Serverless v1 chamado `sample-cluster` e usa a classe de instância de banco de dados `db.r5.xlarge`.
Para Linux, macOS ou Unix:
```
aws rds modify-db-cluster \
--db-cluster-identifier sample-cluster \
--engine-mode provisioned \
--allow-engine-mode-change \
--db-cluster-instance-class db.r5.xlarge
```
Para Windows:
```
aws rds modify-db-cluster ^
--db-cluster-identifier sample-cluster ^
--engine-mode provisioned ^
--allow-engine-mode-change ^
--db-cluster-instance-class db.r5.xlarge
```
O exemplo a seguir demonstra como usar a API do Amazon RDS para converter um cluster de banco de dados do Aurora Serverless v1 em um cluster provisionado.
### API do RDS
Para converter um cluster de banco de dados do Aurora Serverless v1 em um cluster provisionado, use a operação [ModifyDBCluster](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyDBCluster.html) da API.
Os seguintes parâmetros são obrigatórios:
+ `DBClusterIdentifier`: o cluster de banco de dados do Aurora Serverless v1 que você está convertendo em provisionado.
+ `EngineMode`: use o valor `provisioned`.
+ `AllowEngineModeChange`
+ `DBClusterInstanceClass`: escolha a classe da instância de banco de dados para o cluster de banco de dados provisionado com base na capacidade do cluster de banco de dados do Aurora Serverless v1.
## Considerações ao converter um cluster de banco de dados do Aurora Serverless v1 em um cluster provisionado
As seguintes considerações se aplicam quando um cluster de banco de dados do Aurora Serverless v1 é convertido em um cluster provisionado:
+ Você pode usar essa conversão como parte da atualização do cluster de banco de dados de Aurora Serverless v1 para Aurora Serverless v2. Para ter mais informações, consulte [Atualizar a partir de um cluster do Aurora Serverless v1 para o Aurora Serverless v2](aurora-serverless-v2.upgrade.md#aurora-serverless-v2.upgrade-from-serverless-v1-procedure).
+ O processo de conversão cria uma instância de banco de dados do leitor no cluster de banco de dados, promove a instância do leitor a uma instância de gravador e, depois, exclui a instância original do Aurora Serverless v1. Ao converter o cluster de banco de dados, você não pode realizar nenhuma outra modificação ao mesmo tempo, como alterar a versão do mecanismo de banco de dados ou o grupo de parâmetros do cluster de banco de dados. A operação de conversão é aplicada imediatamente e não pode ser desfeita.
+ Durante a conversão, um snapshot do cluster de banco de dados de backup é obtido do cluster de banco de dados caso ocorra um erro. O identificador do snapshot de cluster de banco de dados tem o formato `pre-modify-engine-mode-DB_cluster_identifier-timestamp`.
+ O Aurora usa a versão secundária atual padrão do mecanismo de banco de dados para o cluster de banco de dados provisionado.
+ Se você não fornecer uma classe de instância de banco de dados para o cluster de banco de dados convertido, o Aurora recomendará uma com base na capacidade máxima do cluster de banco de dados original do Aurora Serverless v1. A capacidade recomendada para os mapeamentos de classe de instância é mostrada na tabela a seguir.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/AmazonRDS/latest/AuroraUserGuide/aurora-serverless.modifying.html)
**nota**
Dependendo da classe de instância de banco de dados escolhida e do uso do banco de dados, você pode ver custos diferentes para um cluster de banco de dados provisionado em comparação com o Aurora Serverless v1.
Se você converter o cluster de banco de dados do Aurora Serverless v1 em uma classe de instância de banco de dados expansível (db.t\$1), poderá gerar custos adicionais pelo uso do cluster de banco de dados. Para obter mais informações, consulte [Tipos de classe de instância de banco de dados](Concepts.DBInstanceClass.Types.md).
# Dimensionar manualmente a capacidade do cluster de banco de dados do Aurora Serverless v1
**Importante**
A AWS anunciou [ a data de fim da vida útil do Aurora Serverless v1: 31 de março de 2025](https://repost.aws/questions/QUhcMVoChXRm2HLi8F-yih1g/announcement-support-for-aurora-s/announcement-support-for-aurora-serverless-v1-ending-soon). Todos os clusters do Aurora Serverless v1 que não forem migrados até 31 de março de 2025 serão migrados para o Aurora Serverless v2 durante a janela de manutenção. Se a atualização falhar, durante a janela de manutenção do Amazon Aurora converterá o cluster do Sem Servidor v1 em um cluster provisionado com a versão de mecanismo equivalente. Se aplicável, o Amazon Aurora inscreverá o cluster provisionado convertido no Exporte estendido do Amazon RDS. Para ter mais informações, consulte [Suporte estendido do Amazon RDS com Amazon Aurora](extended-support.md).
Normalmente, os clusters de banco de dados do Aurora Serverless v1 são dimensionados perfeitamente com base na workload. No entanto, a capacidade nem sempre pode escalar rapidamente o suficiente para atender a extremos súbitos, como um aumento exponencial nas transações. Nesses casos, você pode iniciar a operação de escalabilidade manualmente definindo um novo valor de capacidade. Depois de definir a capacidade explicitamente, o Aurora Serverless v1 escalará o cluster de banco de dados automaticamente. Ele faz isso baseado no período de resfriamento para redução.
Você pode definir explicitamente a capacidade de um cluster de banco de dados do Aurora Serverless v1 como um valor específico com o Console de gerenciamento da AWS, a AWS CLI ou a API do RDS.
## Console
Você pode definir a capacidade de um cluster de bancos de dados Aurora com o Console de gerenciamento da AWS.
**Como modificar um cluster de banco de dados do Aurora Serverless v1**
1. Abra o console do Amazon RDS em [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/).
1. No painel de navegação, escolha **Databases (Bancos de dados)**.
1. Escolha o cluster de banco de dados do Aurora Serverless v1 que você deseja modificar.
1. Em **Actions (Ações)**, escolha **Set capacity (Definir capacidade)**.
1. Na janela **Scale database capacity (Dimensionar capacidade do banco de dados)**, escolha o seguinte:
1. Para o seletor suspenso **Scale DB cluster to (Dimensionar cluster de banco de dados para)**, escolha a nova capacidade desejada para o cluster de banco de dados.
1. Na caixa de seleção **If a seamless scaling point cannot be found** (Se não for possível encontrar um ponto de escalabilidade perfeito), escolha o comportamento desejado para a configuração `TimeoutAction` do cluster de banco de dados do Aurora Serverless v1 da seguinte forma:
+ Desmarque essa opção se quiser que a capacidade permaneça inalterada se o Aurora Serverless v1 não conseguir encontrar um ponto de escalabilidade antes do tempo limite.
+ Marque essa opção se quiser forçar o cluster de banco de dados do Aurora Serverless v1 a alterar sua capacidade, mesmo que ele não encontre um ponto de escalabilidade antes do tempo limite. Essa opção pode resultar na liberação de conexões pelo Aurora Serverless v1 que impedem que ele encontre um ponto de escala.
1. Em **seconds** (segundos), insira a quantidade de tempo que você deseja permitir que seu cluster de banco de dados do Aurora Serverless v1 procure um ponto de escalabilidade antes do tempo limite. Você pode especificar em qualquer lugar de 10 segundos a 600 segundos (10 minutos). O padrão é cinco minutos (300 segundos). Este exemplo a seguir força o cluster de banco de dados do Aurora Serverless v1 banco de dados a escalar até 2 ACUs, mesmo que não encontre um ponto de escala dentro de cinco minutos.
![\[Configurar a capacidade de um cluster de banco de dados do Aurora Serverless v1 com o console\]](http://docs.aws.amazon.com/pt_br/AmazonRDS/latest/AuroraUserGuide/images/aurora-serverless-set-capacity.png)
1. Escolha **Apply (Aplicar)**.
Para saber mais sobre pontos de escalabilidade, `TimeoutAction` e períodos de resfriamento, consulte [Autoscaling for Aurora Serverless v1](aurora-serverless-v1.how-it-works.md#aurora-serverless.how-it-works.auto-scaling).
## AWS CLI
Para definir a capacidade de um cluster de banco de dados do Aurora Serverless v1 usando a AWS CLI, execute o comando [modify-current-db-cluster-capacity](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-current-db-cluster-capacity.html) da AWS CLI e especifique a opção `--capacity`. Entre os valores de capacidade válidos estão os seguintes:
+ Aurora MySQL: `1`, `2`, `4`, `8`, `16`, `32`, `64`, `128` e `256`.
+ Aurora PostgreSQL: `2`, `4`, `8`, `16`, `32`, `64`, `192` e `384`.
Neste exemplo, defina a capacidade de um cluster de banco de dados do Aurora Serverless v1 chamado *sample-cluster* como *64*.
```
aws rds modify-current-db-cluster-capacity --db-cluster-identifier sample-cluster --capacity 64
```
## API do RDS
É possível definir a capacidade de um cluster de bancos de dados Aurora com a operação da API [ModifyCurrentDBClusterCapacity](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyCurrentDBClusterCapacity.html). Especifique o parâmetro `Capacity`. Entre os valores de capacidade válidos estão os seguintes:
+ Aurora MySQL: `1`, `2`, `4`, `8`, `16`, `32`, `64`, `128` e `256`.
+ Aurora PostgreSQL: `2`, `4`, `8`, `16`, `32`, `64`, `192` e `384`.
# Visualizar clusters de banco de dados do Aurora Serverless v1
**Importante**
A AWS anunciou [ a data de fim da vida útil do Aurora Serverless v1: 31 de março de 2025](https://repost.aws/questions/QUhcMVoChXRm2HLi8F-yih1g/announcement-support-for-aurora-s/announcement-support-for-aurora-serverless-v1-ending-soon). Todos os clusters do Aurora Serverless v1 que não forem migrados até 31 de março de 2025 serão migrados para o Aurora Serverless v2 durante a janela de manutenção. Se a atualização falhar, durante a janela de manutenção do Amazon Aurora converterá o cluster do Sem Servidor v1 em um cluster provisionado com a versão de mecanismo equivalente. Se aplicável, o Amazon Aurora inscreverá o cluster provisionado convertido no Exporte estendido do Amazon RDS. Para ter mais informações, consulte [Suporte estendido do Amazon RDS com Amazon Aurora](extended-support.md).
Depois de criar um ou mais clusters de banco de dados do Aurora Serverless v1, será possível visualizar quais clusters são do tipo **Serverless (Sem servidor)** e quais são do tipo **Instance (Instância)**. Também é possível visualizar o número atual de unidades de capacidade do Aurora (ACUs) que cada cluster de banco de dados do Aurora Serverless v1 está usando. Cada ACU é uma combinação da capacidade de processamento (CPU) e de memória (RAM).
**Como visualizar os clusters de banco de dados do Aurora Serverless v1**
1. Faça login no Console de gerenciamento da AWS e abra o console do Amazon RDS em [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/).
1. No canto superior direito do Console de gerenciamento da AWS, escolha a Região da AWS em que você criou os clusters de banco de dados do Aurora Serverless v1.
1. No painel de navegação, escolha **Bancos de dados**.
Para cada cluster de banco de dados, o tipo de cluster de banco de dados é mostrado sob **Role (Função)**. Os clusters de banco de dados do Aurora Serverless v1 mostram **Serverless (Sem servidor)** como o tipo. É possível visualizar a capacidade atual de um cluster de banco de dados do Aurora Serverless v1 em **Size (Tamanho)**.
![\[Visualizar clusters de banco de dados do Aurora Serverless v1\]](http://docs.aws.amazon.com/pt_br/AmazonRDS/latest/AuroraUserGuide/images/aurora-serverless-viewing.png)
1. Escolha o nome de um cluster de banco de dados do Aurora Serverless v1 para exibir seus detalhes.
Na guia **Connectivity & security (Conectividade e segurança)**, observe o endpoint do banco de dados. Use esse endpoint para se conectar ao cluster de banco de dados do Aurora Serverless v1.
![\[Visualizar um endpoint de banco de dados do cluster de banco de dados do Aurora Serverless v1\]](http://docs.aws.amazon.com/pt_br/AmazonRDS/latest/AuroraUserGuide/images/aurora-serverless-endpoint.png)
Escolha a guia **Configuration (Configuração)** para visualizar as configurações de capacidade.
![\[Visualizar as configurações de capacidade do cluster de banco de dados do Aurora Serverless v1\]](http://docs.aws.amazon.com/pt_br/AmazonRDS/latest/AuroraUserGuide/images/aurora-serverless-capacity-settings.png)
Um *evento de escalabilidade *é gerado quando o cluster de banco de dados é expandido, reduzido, pausado ou retomado. Escolha a guia **Logs & events (Logs e eventos)** para ver eventos recentes. A imagem a seguir mostra exemplos desses eventos.
![\[Visualizar as configurações de capacidade do cluster de banco de dados do Aurora Serverless v1\]](http://docs.aws.amazon.com/pt_br/AmazonRDS/latest/AuroraUserGuide/images/aurora-serverless-scaling.png)
## Monitorar a capacidade e eventos de escalabilidade do seu cluster de banco de dados do Aurora Serverless v1
Você pode visualizar seu cluster de banco de dados do Aurora Serverless v1 no CloudWatch para monitorar a capacidade alocada ao cluster de banco de dados com a métrica `ServerlessDatabaseCapacity`. Você também pode monitorar todas as métricas padrão do CloudWatch para o Aurora, como `CPUUtilization`, `DatabaseConnections`, `Queries` e assim por diante.
Você pode fazer com que o Aurora publique alguns ou todos os logs de banco de dados no CloudWatch. Você seleciona os logs a serem publicados habilitando os parâmetros de configuração [, como `general_log` e `slow_query_log`, no grupo de parâmetros do cluster de banco de dados](aurora-serverless-v1.how-it-works.md#aurora-serverless.parameter-groups) associado ao cluster do Aurora Serverless v1. Ao contrário dos clusters provisionados, os clusters do Aurora Serverless v1 não necessitam que você especifique nas configurações do cluster de banco de dados que tipos de log ser carregados no CloudWatch. Os clusters do Aurora Serverless v1 carregam automaticamente todos os logs disponíveis. Quando você desativa um parâmetro de configuração de log, a publicação do log no CloudWatch é interrompida. Você também pode excluir os logs no CloudWatch se eles não forem mais necessários.
Para começar a usar o Amazon CloudWatch para seu cluster de banco de dados do Aurora Serverless v1, consulte [Visualizar logs do Aurora Serverless v1 com o Amazon CloudWatch](aurora-serverless-v1.how-it-works.md#aurora-serverless.logging.monitoring). Para saber mais sobre como monitorar clusters de Aurora banco de dados por meio de CloudWatch, consulte [Monitorar eventos de log no Amazon CloudWatch](AuroraMySQL.Integrating.CloudWatch.md#AuroraMySQL.Integrating.CloudWatch.Monitor).
Para se conectar a um cluster de banco de dados do Aurora Serverless v1, use o endpoint do banco de dados. Para obter mais informações, consulte [Como conectar-se a um cluster de bancos de dados Amazon Aurora](Aurora.Connecting.md).
**nota**
Não é possível conectar diretamente a instâncias de banco de dados específicas em seus clusters de banco de dados do Aurora Serverless v1.
# Excluir um cluster de banco de dados do Aurora Serverless v1
**Importante**
A AWS anunciou [ a data de fim da vida útil do Aurora Serverless v1: 31 de março de 2025](https://repost.aws/questions/QUhcMVoChXRm2HLi8F-yih1g/announcement-support-for-aurora-s/announcement-support-for-aurora-serverless-v1-ending-soon). Todos os clusters do Aurora Serverless v1 que não forem migrados até 31 de março de 2025 serão migrados para o Aurora Serverless v2 durante a janela de manutenção. Se a atualização falhar, durante a janela de manutenção do Amazon Aurora converterá o cluster do Sem Servidor v1 em um cluster provisionado com a versão de mecanismo equivalente. Se aplicável, o Amazon Aurora inscreverá o cluster provisionado convertido no Exporte estendido do Amazon RDS. Para ter mais informações, consulte [Suporte estendido do Amazon RDS com Amazon Aurora](extended-support.md).
Dependendo de como você cria um cluster de banco de dados do Aurora Serverless v1, a proteção contra exclusão pode estar ativada por padrão. Você não pode excluir imediatamente um cluster de Aurora Serverless v1 banco de dados que tenha a **proteção de exclusão** ativada. Para excluir clusters de Aurora Serverless v1 banco de dados que têm proteção contra exclusão usando o Console de gerenciamento da AWS, primeiro modifique o cluster para remover essa proteção. Para obter informações sobre como usar o AWS CLI para esta tarefa, consulte [AWS CLI](#aurora-serverless.delete.cli).
**Para desabilitar a proteção contra exclusão usando o Console de gerenciamento da AWS**
1. Faça login no Console de gerenciamento da AWS e abra o console do Amazon RDS em [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/).
1. No painel de navegação, escolha **DB clusters (Clusters de banco de dados)**.
1. Escolha seu cluster de Aurora Serverless v1 banco de dados na lista.
1. Escolha **Modificar** para abrir a configuração do cluster de banco de dados. A página Modificar cluster de banco de dados abre as configurações, configurações de capacidade e outros detalhes de configuração para seu cluster de Aurora Serverless v1 banco de dados. A proteção contra exclusão está na seção **Configuração adicional** .
1. Desmarque a caixa de seleção **Enable deletion protection** (Habilitar proteção contra exclusão) no cartão de propriedades **Additional configuration** (Configuração adicional).
1. Escolha **Continue**. Você verá o **Summary of modifications (Resumo das modificações)**.
1. Escolha **Modify cluster (Modificar cluster)** para aceitar o resumo das modificações. Você também pode escolher **BAck (Voltar)** para modificar suas alterações ou **Cancel (Cancelar)** para descartar suas alterações.
Depois que a proteção contra exclusão não estiver mais ativa, você poderá excluir seu cluster de Aurora Serverless v1 banco de dados usando Console de gerenciamento da AWSo.
## Console
**Para excluir um cluster de banco de dados do Aurora Serverless v1**
1. Faça login no Console de gerenciamento da AWS e abra o console do Amazon RDS em [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/).
1. Na seção **Resources (Recursos)**, escolha **DB Clusters (Clusters de banco de dados)**.
1. Escolha o cluster de banco de dados do Aurora Serverless v1 que você deseja excluir.
1. Em **Actions**, escolha **Delete**. Você será solicitado a confirmar se deseja excluir seu cluster de Aurora Serverless v1 banco de dados.
1. Recomendamos que você mantenha as opções pré-selecionadas:
+ **Yes (Sim)** para **Create final snapshot? (Criar snapshot final?)**
+ O nome do cluster de banco de dados do Aurora Serverless v1 mais `-final-snapshot` para **Final snapshot name (Nome do snapshot final)**. No entanto, você pode alterar o nome do snapshot final neste campo.
![\[Captura de tela da exclusão do cluster Aurora Serverless v1 de banco de dados\]](http://docs.aws.amazon.com/pt_br/AmazonRDS/latest/AuroraUserGuide/images/aurora-sles-delete-db-1.png)
Se você escolher **No (Não)** para **Create final snapshot? (Criar snapshot final?)** você não pode restaurar seu cluster de banco de dados usando snapshots ou recuperação em um ponto anterior no tempo.
1. Escolha **Delete DB cluster (Excluir cluster de banco de dados)**.
Aurora Serverless v1 exclui seu cluster de banco de dados. Se você optar por ter um snapshot final, verá o status do cluster de Aurora Serverless v1 banco de dados mudar para “Backing-up” antes de ser excluído e não aparecer mais na lista.
## AWS CLI
Antes de começar, configure sua AWS CLI com o ID da chave de acesso da AWS, a chave de acesso secreta da AWS e a Região da AWS onde está seu cluster de banco de dados do Aurora Serverless v1. Para obter mais informações, consulte [Conceitos básicos de configuração](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-quickstart.html#cli-configure-quickstart-config) no Guia do usuário da AWS Command Line Interface.
Você não pode excluir um cluster de Aurora Serverless v1 banco de dados até depois de desativar a proteção contra exclusão para clusters configurados com essa opção. Se você tentar excluir um cluster que tenha essa opção de proteção ativada, verá a seguinte mensagem de erro.
```
1. An error occurred (InvalidParameterCombination) when calling the DeleteDBCluster
2. operation: Cannot delete protected Cluster, please disable deletion protection and try again.
```
Você pode alterar a configuração de proteção contra exclusão do cluster de Aurora Serverless v1 banco de dados usando o AWS CLI comando [modify-db-cluster](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-cluster.html) , conforme mostrado no seguinte:
```
aws rds modify-db-cluster --db-cluster-identifier your-cluster-name --no-deletion-protection
```
Este comando retorna as propriedades revisadas para o cluster de banco de dados especificado. Agora você pode excluir seu cluster de Aurora Serverless v1 banco de dados.
Recomendamos que você sempre crie um snapshot final sempre que excluir um cluster de Aurora Serverless v1 banco de dados. O exemplo a seguir de usar o AWS CLI [delete-db-cluster](https://docs.aws.amazon.com/cli/latest/reference/rds/delete-db-cluster.html) mostra como. Você fornece o nome do cluster de banco de dados e um nome para o snapshot.
Para Linux, macOS ou Unix:
```
aws rds delete-db-cluster --db-cluster-identifier \
your-cluster-name --no-skip-final-snapshot \
--final-db-snapshot-identifier name-your-snapshot
```
Para Windows:
```
aws rds delete-db-cluster --db-cluster-identifier ^
your-cluster-name --no-skip-final-snapshot ^
--final-db-snapshot-identifier name-your-snapshot
```
# Aurora Serverless v1Versões de mecanismos de banco de dados do e do Aurora
**Importante**
A AWS anunciou [ a data de fim da vida útil do Aurora Serverless v1: 31 de março de 2025](https://repost.aws/questions/QUhcMVoChXRm2HLi8F-yih1g/announcement-support-for-aurora-s/announcement-support-for-aurora-serverless-v1-ending-soon). Todos os clusters do Aurora Serverless v1 que não forem migrados até 31 de março de 2025 serão migrados para o Aurora Serverless v2 durante a janela de manutenção. Se a atualização falhar, durante a janela de manutenção do Amazon Aurora converterá o cluster do Sem Servidor v1 em um cluster provisionado com a versão de mecanismo equivalente. Se aplicável, o Amazon Aurora inscreverá o cluster provisionado convertido no Suporte estendido do Amazon RDS. Para obter mais informações, consulte [Suporte estendido do Amazon RDS com Amazon Aurora](extended-support.md).
O Aurora Serverless v1 está disponível em determinadas Regiões da AWS e somente para versões específicas do Aurora MySQL e do Aurora PostgreSQL. Para obter a lista atual de Regiões da AWS que são compatíveis com o Aurora Serverless v1 e as versões específicas do Aurora MySQL e do Aurora PostgreSQL disponíveis em cada região, consulte [Aurora Serverless v1 da](Concepts.Aurora_Fea_Regions_DB-eng.Feature.ServerlessV1.md).
Aurora Serverless v1O usa seu mecanismo de banco de dados do Aurora associado para identificar versões compatíveis específicas para cada mecanismo de banco de dados compatível, deste modo:
+ Aurora MySQL Serverless
+ Aurora PostgreSQL Serverless
Quando versões secundárias dos mecanismos de banco de dados ficam disponíveis para o Aurora Serverless v1, elas são aplicadas automaticamente nas várias Regiões da AWS onde o Aurora Serverless v1 está disponível. Em outras palavras, você não precisa atualizar seu cluster de Aurora Serverless v1 banco de dados para obter uma nova versão secundária para o mecanismo de banco de dados do cluster quando ele estiver disponível para Aurora Serverless v1.
## Aurora MySQL Serverless
O Aurora Serverless v1 está disponível em determinadas Regiões da AWS e somente para versões específicas do Aurora MySQL. Para obter a lista atual de Regiões da AWS compatíveis com o Aurora Serverless v1 e as versões específicas do Aurora MySQL disponíveis em cada região, consulte [Aurora Serverless v1 com o Aurora MySQL](Concepts.Aurora_Fea_Regions_DB-eng.Feature.ServerlessV1.md#Concepts.Aurora_Fea_Regions_DB-eng.Feature.ServerlessV1.amy).
Para saber mais sobre aprimoramentos e correções de erros para o Aurora MySQL versão 2, consulte [Atualizações do mecanismo de banco de dados Amazon Aurora MySQL](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraMySQLReleaseNotes/AuroraMySQL.Updates.20Updates.html) nas *Notas de versão do Aurora MySQL*.
Para usar uma versão mais recente do Aurora MySQL, é possível usar o Aurora Serverless v2. Para saber quais Regiões da AWS e versões do Aurora MySQL podem ser usadas com o Aurora Serverless v2, consulte [Aurora Serverless v2 com o Aurora MySQL](Concepts.Aurora_Fea_Regions_DB-eng.Feature.ServerlessV2.md#Concepts.Aurora_Fea_Regions_DB-eng.Feature.ServerlessV2.amy). Para ter informações de uso do Aurora Serverless v2, consulte [Usar o Aurora Serverless v2](aurora-serverless-v2.md).
## Aurora PostgreSQL Serverless
O Aurora Serverless v1 está disponível em determinadas Regiões da AWS e somente para versões específicas do Aurora PostgreSQL. Para obter a lista atual de Regiões da AWS compatíveis com o Aurora Serverless v1 e as versões específicas do Aurora PostgreSQL disponíveis em cada região, consulte [Aurora Serverless v1 com o Aurora PostgreSQL](Concepts.Aurora_Fea_Regions_DB-eng.Feature.ServerlessV1.md#Concepts.Aurora_Fea_Regions_DB-eng.Feature.ServerlessV1.apg).
Se você quiser usar o Aurora PostgreSQL para o cluster de banco de dados do Aurora Serverless v1, poderá usar as versões compatíveis com o Aurora PostgreSQL 13. Versões menores para Aurora Edição compatível com PostgreSQL incluir apenas alterações compatíveis com versões anteriores. Seu cluster de banco de dados do Aurora Serverless v1 é atualizado de forma transparente quando uma versão secundária do Aurora PostgreSQL se torna disponível para o Aurora Serverless v1 em sua Região da AWS.
Para usar uma versão mais recente do Aurora PostgreSQL, é possível usar o Aurora Serverless v2. Para saber quais Regiões da AWS e versões do Aurora PostgreSQL podem ser usadas com o Aurora Serverless v2, consulte [Aurora Serverless v2 com o Aurora PostgreSQL](Concepts.Aurora_Fea_Regions_DB-eng.Feature.ServerlessV2.md#Concepts.Aurora_Fea_Regions_DB-eng.Feature.ServerlessV2.apg). Para ter informações de uso do Aurora Serverless v2, consulte [Usar o Aurora Serverless v2](aurora-serverless-v2.md).
## Atualizações automáticas da versão secundária do Aurora Serverless v1
Quando versões secundárias dos mecanismos de banco de dados ficam disponíveis para o Aurora Serverless v1, elas são aplicadas automaticamente nas várias Regiões da AWS onde o Aurora Serverless v1 está disponível. Em outras palavras, você não precisa atualizar seu cluster de Aurora Serverless v1 banco de dados para obter uma nova versão secundária para o mecanismo de banco de dados do cluster quando ele estiver disponível para Aurora Serverless v1.