O Amazon Redshift não permitirá mais a criação de UDFs do Python a partir do Patch 198. As UDFs do Python existentes continuarão a funcionar normalmente até 30 de junho de 2026. Para ter mais informações, consulte a [publicação de blog ](https://aws.amazon.com/blogs/big-data/amazon-redshift-python-user-defined-functions-will-reach-end-of-support-after-june-30-2026/). 

# Operações de cluster
<a name="managing-cluster-operations"></a>

Depois de criar um cluster, você pode realizar operações de cluster para otimizar a performance, controlar os custos e garantir alta disponibilidade. As operações de cluster permitem redimensionar, pausar, retomar ou até mesmo recriar clusters à medida que suas necessidades de armazenamento de dados evoluem. 

Casos de uso comuns incluem escalar a capacidade computacional para workloads de pico, pausar clusters durante períodos inativos para reduzir custos e recriar clusters com configurações diferentes ou em zonas de disponibilidade distintas para recuperação de desastres. As seções a seguir abordam os detalhes da execução de várias operações de cluster para gerenciar com eficiência o ambiente do Amazon Redshift.

# Criar um cluster
<a name="create-cluster"></a>

Com o Amazon Redshift, é possível pode criar um cluster provisionado para iniciar um novo data warehouse. Um cluster provisionado é um conjunto de recursos de computação chamados nós, os quais são organizados em um único sistema de processamento maciçamente paralelo (MPP). 

Antes de criar um cluster, leia [Clusters provisionados do Amazon Redshift](working-with-clusters.md) e [Clusters e nós no Amazon Redshift](working-with-clusters.md#rs-about-clusters-and-nodes).

**Para criar um cluster**

1. Faça login no Console de gerenciamento da AWS e abra o console do Amazon Redshift em [https://console.aws.amazon.com/redshiftv2/](https://console.aws.amazon.com/redshiftv2/).

1. No menu de navegação, escolha **Clusters**. Os clusters de sua conta na região atual da AWS são listados. Um subconjunto de propriedades de cada cluster é exibido nas colunas na lista. 

1. Escolha **Create cluster** (Criar cluster) para criar um cluster. 

1. Siga as instruções na página do console para inserir as propriedades de **Cluster configuration** (Configuração do cluster). 

   A etapa a seguir descreve um console do Amazon Redshift que está sendo executado em uma Região da AWS compatível com tipos de nó RA3. Para conferir a lista de Regiões da AWS compatíveis com tipos de nó RA3, consulte [Visão geral dos tipos de nó RA3](https://docs.aws.amazon.com/redshift/latest/mgmt/working-with-clusters.html#rs-ra3-node-types) no *Guia de gerenciamento do Amazon Redshift*. 

   Se você não souber o tamanho do cluster, escolha **Ajude-me a escolher**. Isso inicia uma calculadora de dimensionamento que faz perguntas sobre o tamanho e as características de consulta dos dados que você planeja armazenar em seu data warehouse. Se você souber o tamanho necessário do cluster (ou seja, o tipo de nó e o número de nós), escolha **Eu escolherei**. Em seguida, escolha o **Tipo de nó** e número de **Nós** para dimensionar seu cluster para a prova de conceito.
**nota**  
Se sua organização for elegível e seu cluster estiver sendo criado em uma Região da AWS em que o Amazon Redshift sem servidor não está indisponível, você poderá criar um cluster no programa de teste gratuito do Amazon Redshift. Escolha **Produção** ou **Teste gratuito** para responder à pergunta **Para que você está planejando usar esse cluster?** Ao escolher **Teste gratuito**, você crie uma configuração com o tipo de nó dc2.large. Para obter mais informações sobre a escolha de um teste gratuito, consulte [Teste gratuito do Amazon Redshift](https://aws.amazon.com/redshift/free-trial/). Para obter uma lista de Regiões da AWS nas quais o Amazon Redshift sem servidor está disponível, consulte os endpoints listados para a [API do Redshift sem servidor](https://docs.aws.amazon.com/general/latest/gr/redshift-service.html) na *Referência geral da Amazon Web Services*. 

1. Na seção **Configuração do banco de dados**, especifique um valor para **Nome do usuário administrador**. Em **Senha do administrador**, é possível escolher uma das seguintes opções:
   +  **Gere uma senha**: use uma senha gerada pelo Amazon Redshift. 
   +  **Adicionar manualmente uma senha de administrador**: use a própria senha. 
   +  **Gerenciar credenciais de administrador no AWS Secrets Manager**: o Amazon Redshift usa AWS Secrets Manager para gerar e gerenciar a senha de administrador. O uso do AWS Secrets Manager para gerar e gerenciar o segredo da senha incorre em uma taxa. Para obter informações sobre definição de preços do AWS Secrets Manager, consulte [Definição de preços do AWS Secrets Manager](https://aws.amazon.com/secrets-manager/pricing/). 

1. (Opcional) Siga as instruções na página do console para inserir as propriedades de**Cluster permissions (Permissões do cluster)**. Forneça permissões de cluster se seu cluster precisar acessar outros serviços da AWS para você, por exemplo, para carregar dados do Amazon S3. 

1. Para criar o cluster, escolha **Create cluster** (Criar cluster). Podem ser necessários alguns minutos para preparar o cluster para ser usado.

## Configurações adicionais
<a name="cluster-create-console-configuration"></a>

Ao criar um cluster, é possível especificar propriedades adicionais para personalizá-lo. Você pode encontrar mais detalhes sobre algumas dessas propriedades na lista a seguir. 

**Tipo de endereço IP**  
Escolha o tipo de endereço IP para o cluster. É possível optar por fazer com que os recursos só se comuniquem via protocolo de endereçamento IPv4 ou escolher o modo de pilha dupla, o que permite que os recursos se comuniquem via IPv4 e IPv6. Esse recurso só está disponível nas regiões GovCloud (EUA-Leste) da AWS e GovCloud (EUA-Oeste) da AWS. Para obter mais informações sobre regiões da AWS, consulte [Regions and Availability Zones](https://aws.amazon.com/about-aws/global-infrastructure/regions_az/).

**Nuvem privada virtual (VPC)**  
Escolha uma VPC que tenha um grupo de sub-redes do cluster. Depois que o cluster for criado, o grupo de sub-redes do cluster não poderá ser alterado. 

**Grupos de parâmetros**  
Selecione um parameter group de cluster para associar ao cluster. Se você não selecionar um, o cluster usará um parameter group padrão. 

**Criptografia**  
Selecione se deseja criptografar todos os dados no cluster e nos snapshots. Se você deixar a configuração padrão, **None**, a criptografia não será habilitada. Se desejar habilitar a criptografia, escolha se deseja usar o AWS Key Management Service (AWS KMS) ou um módulo de segurança de hardware (HSM) e defina as configurações relacionadas. Para obter mais informações sobre criptografia no Amazon Redshift, consulte [Criptografia de banco de dados do Amazon Redshift](working-with-db-encryption.md).  
+ **KMS**

  Selecione **Usar o AWS Key Management Service (AWS KMS)** se quiser habilitar a criptografia e usar o AWS KMS para gerenciar a chave de criptografia. Escolha também a tecla para usar. É possível escolher uma chave padrão, uma chave da conta atual ou uma chave de outra conta.
**nota**  
Se você desejar usar uma chave de outra conta da AWS, insira o nome do recurso da Amazon (ARN) da chave a ser utilizada. É preciso ter permissão para usar a chave. Para obter mais informações sobre acesso às chaves no AWS KMS, consulte [Controlar o acesso às chaves](https://docs.aws.amazon.com/kms/latest/developerguide/control-access.html) no *Guia do desenvolvedor do AWS Key Management Service*.

  Para obter mais informações sobre criptografia AWS KMS no Amazon Redshift, consulte [Criptografia por meio do AWS KMS](working-with-db-encryption.md#working-with-aws-kms).
+ **HSM**

  Escolha **HSM** se deseja habilitar a criptografia e usar o módulo de segurança de hardware (HSM) para gerenciar sua chave de criptografia.

  Se você escolher **HSM**, selecione os valores em **HSM Connection (Conexão HSM)** e **HSM Client Certificate (Certificado do cliente HSM)**. Esses valores são necessários para que o Amazon Redshift e o HSM formem uma conexão confiável pela qual a chave do cluster pode ser passada. A conexão HSM e o certificado do cliente devem ser configurados no Amazon Redshift antes de iniciar um cluster. Para obter mais informações sobre como configurar conexões de HSM e certificados do cliente, consulte [Criptografia por meio de módulos de segurança de hardware](working-with-db-encryption.md#working-with-HSM).

**Maintenance track (Acompanhamento de manutenção**  
É possível escolher se a versão usada do cluster é a **Current (Atual)**, **Trailing (Inicial)** ou, algumas vezes, a trilha **Preview (Demonstração)**. 

**Monitoramento**  
Você pode escolher se deseja criar alarmes CloudWatch. 

**Configure cross-region snapshot (Configurar snapshots entre regiões**  
É possível escolher se deseja habilitar snapshots entre regiões. 

**Automated Snapshot Retention Period (Período de retenção de snapshot automático**  
Você pode escolher o número de dias para reter esses snapshots dentro de 35 dias. Se o tipo de nó for DC2, você poderá escolher zero (0) dia para não criar snapshots automáticos.

**Manual snapshot retention period (Período de retenção de snapshot manual**  
Você pode escolher o número de dias ou `Indefinitely` para reter esses snapshots. 

**Recursos extras de computação para otimizações automáticas**  
Você pode escolher se deseja alocar recursos extras de computação para realizar otimizações automáticas, mesmo durante períodos de uso intenso. Para ter mais informações, consulte [Alocação de recursos extras de computação para otimização automática de banco de dados](https://docs.aws.amazon.com/redshift/latest/dg/t_extra-compute-autonomics.html) no *Guia do desenvolvedor de banco de dados do Amazon Redshift*.

# Criar um alarme de espaço em disco
<a name="rs-mgmt-edit-default-disk-space-alarm"></a>

É possível monitorar o uso do espaço em disco e definir alarmes para receber notificação quando o espaço em disco exceder um limite especificado para um cluster. A criação de um alarme de uso do espaço em disco permite gerenciar proativamente a capacidade de armazenamento e evitar problemas decorrentes de espaço em disco insuficiente, como falhas de consulta ou erros de ingestão de dados. O procedimento a seguir conduz você pelo processo de criação de um alarme de uso do espaço em disco.

**Para criar um alarme de uso de espaço em disco de um cluster**

1. Faça login no Console de gerenciamento da AWS e abra o console do Amazon Redshift em [https://console.aws.amazon.com/redshiftv2/](https://console.aws.amazon.com/redshiftv2/).

1. No menu de navegação, escolha **Alarms** (Alarmes). 

1. Em **Actions (Ações)**, escolha **Create alarm (Criar alarme)**. A página **Create alarm (Criar alarme)** é exibida.

1. Siga as instruções na página. 

1. Selecione **Criar alarme**.

# Visualizar um cluster
<a name="view-cluster"></a>

A visualização de um cluster permite monitorar e gerenciar a configuração, o status e as métricas de performance do cluster. Ao visualizar os detalhes do cluster, você pode obter insights sobre utilização de recursos, tempos de execução das consultas e integridade do sistema. O procedimento a seguir mostra como acessar informações do cluster.

**Como visualizar um cluster**

1. Faça login no Console de gerenciamento da AWS e abra o console do Amazon Redshift em [https://console.aws.amazon.com/redshiftv2/](https://console.aws.amazon.com/redshiftv2/).

1. No menu de navegação, escolha **Clusters**. Os clusters de sua conta na região atual da AWS são listados. Um subconjunto de propriedades de cada cluster é exibido nas colunas na lista. Se você não tiver nenhum cluster, escolha **Create cluster (Criar cluster)** para criar um.

1. Escolha o nome do cluster na lista para visualizar mais detalhes sobre o cluster.

# Modificar um cluster
<a name="modify-cluster"></a>

Ao modificar um cluster, as alterações nas seguintes opções são aplicadas automaticamente:
+ **Grupos de segurança da VPC** 
+ **Acessível ao público** 
+ **Admin user password (Senha do usuário administrador** 
+ **Conexão HSM** 
+ **HSM Client Certificate** 
+ **Detalhes da manutenção** 
+ **Snapshot preferences (Preferências de snapshot** 

 As alterações nas seguintes opções serão implementadas somente depois que o cluster for reiniciado:
+ **Identificador de Cluster**

  O Amazon Redshift reinicia o cluster automaticamente quando você altera o **Identificador de cluster**.
+ **Enhanced VPC routing**

  O Amazon Redshift reinicia o cluster automaticamente quando você altera o **Roteamento aprimorado da VPC**.
+ **Grupo de parâmetros do cluster** 
+ **Tipo de endereço IP** 

  Esse recurso só está disponível nas regiões GovCloud (EUA-Leste) da AWS e GovCloud (EUA-Oeste) da AWS. Para obter mais informações sobre regiões da AWS, consulte [Regions and Availability Zones](https://aws.amazon.com/about-aws/global-infrastructure/regions_az/).

Se você diminuir o período de retenção de snapshot automatizado, os snapshots automatizados existentes cujas configurações estejam fora do novo período de retenção serão excluídos. Para obter mais informações, consulte [Snapshots e backups do Amazon Redshift](working-with-snapshots.md). 

Para obter mais informações sobre as propriedades do cluster, consulte [Configurações adicionais](create-cluster.md#cluster-create-console-configuration). 

**Como modificar um cluster**

1. Faça login no Console de gerenciamento da AWS e abra o console do Amazon Redshift em [https://console.aws.amazon.com/redshiftv2/](https://console.aws.amazon.com/redshiftv2/).

1. No menu de navegação, escolha **Clusters**. 

1. Escolha o cluster a ser modificado. 

1. Escolha **Editar**. A página **Editar cluster** é exibida.

1. Atualize as propriedades do cluster. Algumas das propriedades que você pode modificar são: 
   + Identificador de Cluster
   + Retenção de snapshots
   + Realocação de cluster

   Para editar configurações de **Rede e segurança**, **Manutenção** e **Configurações do banco de dados**, o console fornece links para a guia de detalhes do cluster apropriada.

1. Escolha **Salvar alterações**.

# Redimensionamento de um cluster
<a name="resizing-cluster"></a>

À medida que a sua capacidade e necessidades de desempenho do data warehousing mudam ou aumentam, é possível redimensionar seu cluster para fazer o melhor uso das opções de computação e armazenamento que o Amazon Redshift oferece. 

 Ao redimensionar um cluster, você especifica vários nós ou tipos de nó diferentes da configuração atual do cluster. Enquanto o cluster está no processo de redimensionamento, não é possível executar consultas que façam operações de gravação ou leitura/gravação no cluster. Somente a leitura de consultas é possível. 

 Para obter mais informações sobre o redimensionamento de clusters, incluindo uma demonstração do processo de redimensionamento de clusters usando diferentes abordagens, consulte [Redimensionamento de um cluster](#resizing-cluster). 

**Para redimensionar um cluster**

1. Faça login no Console de gerenciamento da AWS e abra o console do Amazon Redshift em [https://console.aws.amazon.com/redshiftv2/](https://console.aws.amazon.com/redshiftv2/).

1. No menu de navegação, escolha **Clusters**. 

1. Escolha o cluster a ser redimensionado. 

1. Em **Actions (Ações)**, escolha **Resize (Redimensionar)**. A página **Resize cluster (Redimensionar cluster)** é exibida.

1. Siga as instruções na página. Você pode redimensionar o cluster agora, uma vez em um momento específico, ou aumentar e diminuir o tamanho do cluster definindo uma programação.

1. Dependendo das suas opções, escolha **Resize now (Redimensionar agora)** ou **Schedule resize (Agendar redimensionamento)**. 

Se você tiver nós reservados, poderá atualizar para nós reservados RA3. Faça isso usando o console para restaurar a partir de um snapshot ou para executar um redimensionamento elástico. Você pode usar o console se orientar nesse processo. Para obter mais informações sobre a atualização para nós RA3, consulte [Atualizar para os tipos de nó RA3](https://docs.aws.amazon.com/redshift/latest/mgmt/working-with-clusters.html#rs-upgrading-to-ra3). 

Quando você executa uma operação de redimensionamento para atualizar um tipo de nó DC2.large para um tipo de nó RA3.large, o Amazon Redshift converte automaticamente as chaves de classificação intercaladas em chaves de classificação compostas. Essa conversão possibilita o acesso ao recurso escalabilidade simultânea, que não permite consultas em tabelas com chaves de classificação intercaladas. Embora essa conversão automática garanta compatibilidade com os recursos do RA3, ela pode afetar seus padrões atuais de desempenho de consulta. 

Se quiser manter as chaves de classificação intercaladas após a atualização para os nós RA3, você pode recriar suas tabelas com a configuração de chave de classificação desejada após a conclusão da operação de redimensionamento. No entanto, ao escolher essa opção, você não poderá usar a escalabilidade simultânea para essas tabelas.

Há dois tipos de operação de redimensionamento:
+ **Redimensionamento elástico** - É possível adicionar ou remover nós do cluster. Também é possível alterar o tipo de nó, como de nós DC2 para nós RA3. Um redimensionamento elástico normalmente é concluído rapidamente, levando dez minutos, em média. Por esse motivo, é recomendável como primeira opção. Quando você executa um redimensionamento elástico, ele redistribui fatias de dados, que são partições que recebem memória e espaço em disco alocados em cada nó. O redimensionamento elástico é apropriado quando você:
  + *Adiciona ou reduz nós em um cluster existente, mas não altera o tipo de nó* - Isso é comumente chamado de redimensionamento *no local*. Quando você executa esse tipo de redimensionamento, algumas consultas em execução são concluídas com êxito, mas outras podem ser descartadas como parte da operação.
  + *Alterar o tipo de nó de um cluster*: quando você altera o tipo de nó, um snapshot é criado e os dados são redistribuídos do cluster de origem para um cluster composto pelo novo tipo de nó. Após a conclusão, as consultas em execução são descartadas. Como acontece com o redimensionamento *no local*, ele é realizado rapidamente.
+ **Redimensionamento clássico** - É possível alterar o tipo de nó, o número de nós ou ambos, de maneira semelhante ao redimensionamento elástico. O redimensionamento clássico leva mais tempo para ser concluído, mas pode ser útil nos casos em que a alteração na contagem de nós ou no tipo de nó para o qual migrar não se enquadra nos limites do redimensionamento elástico. Isso pode se aplicar, por exemplo, quando a alteração na contagem de nós é muito grande. 

**Topics**
+ [Elastic resize (Redimensionamento elástico)](#elastic-resize)
+ [Classic resize (Redimensionamento clássico)](#classic-resize-faster)

## Elastic resize (Redimensionamento elástico)
<a name="elastic-resize"></a>

Uma operação de redimensionamento elástico, quando você adiciona ou remove nós do mesmo tipo, tem os seguintes estágios:

1. O redimensionamento elástico tira um snapshot do cluster. Tabelas sem backup são aceitas somente em nós DC2. Para todos os outros tipos de cluster, tabelas sem backup são incluídas no snapshot. Para obter mais informações, consulte [Excluir tabelas de snapshots](working-with-snapshots.md#snapshots-no-backup-tables). Se o cluster não tiver um snapshot recente porque você desabilitou os snapshots automatizados, a operação de backup pode levar mais tempo. Para minimizar o tempo antes do início da operação de redimensionamento, recomendamos que você habilite snapshots automatizados ou crie um snapshot manual antes de iniciar um redimensionamento elástico. Quando você inicia um redimensionamento elástico e uma operação de snapshot está em andamento, o redimensionamento elástico poderá falhar se a operação de snapshot não for concluída em alguns minutos. Para obter mais informações, consulte [Snapshots e backups do Amazon Redshift](working-with-snapshots.md).

1. A operação migra os metadados do cluster. O cluster fica indisponível por alguns minutos. A maioria das consultas é temporariamente pausada e as conexões são mantidas abertas. É possível, no entanto, que algumas consultas sejam descartadas. Esse estágio é curto.

1. As conexões de sessão são restabelecidas e as consultas são retomadas. 

1. O redimensionamento elástico redistribui os dados para as fatias do nó no plano de fundo. O cluster está disponível para operações de leitura e gravação, mas algumas consultas podem levar mais tempo para serem executadas.

1. Após a conclusão da operação, o Amazon Redshift envia uma notificação de evento.

Quando você usa o redimensionamento elástico para alterar o tipo de nó, ele funciona de forma semelhante a quando você adiciona ou subtrai nós do mesmo tipo. Primeiro, um snapshot é criado. Um novo cluster de destino é provisionado com os dados mais recentes do snapshot e os dados são transferidos para o novo cluster em segundo plano. Durante esse período, os dados são somente leitura. Quando o redimensionamento está perto de ser concluído, o Amazon Redshift atualiza o endpoint do novo cluster e todas as conexões com o cluster de origem são descartadas.

É improvável que um redimensionamento elástico falhe. No entanto, no caso de falha, a reversão ocorre automaticamente na maioria dos casos, sem a necessidade de intervenção manual.

Se você tiver nós reservados, por exemplo nós reservados DC2, poderá atualizar para nós reservados RA3 quando realizar um redimensionamento. Você pode fazer isso ao executar um redimensionamento elástico ou ao usar o console para restaurar a partir de um snapshot. Este guia de console orientará você durante esse processo. Para obter mais informações sobre a atualização para nós RA3, consulte [Atualizar para os tipos de nó RA3](https://docs.aws.amazon.com/redshift/latest/mgmt/working-with-clusters.html#rs-upgrading-to-ra3). 

O redimensionamento elástico não classifica tabelas ou recupera espaço em disco; por isso, não é um substituto para uma operação de vacuum. Para obter mais informações, consulte [Vacuum de tabelas](https://docs.aws.amazon.com/redshift/latest/dg/t_Reclaiming_storage_space202.html).

O redimensionamento elástico tem as seguintes restrições:
+ *Redimensionamento elástico clusters de compartilhamento de dados*: ao adicionar ou subtrair nós em um cluster que é um produtor para compartilhamento de dados, você não pode se conectar a ele por meio dos consumidores enquanto o Amazon Redshift estiver migrando metadados de cluster. Da mesma forma, se você executar um redimensionamento elástico e escolher um novo tipo de nó, o compartilhamento de dados ficará indisponível enquanto as conexões são descartadas e transferidas para o novo cluster de destino. Nos dois tipos de redimensionamento elástico, o produtor fica indisponível por vários minutos.
+ *Transferência de dados de um snapshot compartilhado*: para executar um redimensionamento elástico em um cluster que está transferindo dados de um snapshot compartilhado, pelo menos um backup deve estar disponível para o cluster. Você pode visualizar seus backups na lista de snapshots do console do Amazon Redshift, no comando CLI `describe-cluster-snapshots` ou na operação da API `DescribeClusterSnapshots`.
+ *Restrição de plataforma*: o redimensionamento elástico está disponível apenas para clusters que usam a plataforma EC2-VPC. Para obter mais informações, consulte [Usar o EC2 para criar um cluster](working-with-clusters.md#cluster-platforms). 
+ *Considerações de armazenamento* - Certifique-se de que a configuração do novo nó tem armazenamento suficiente para os dados existentes. Talvez seja necessário adicionar nós ou alterar a configuração. 
+ *Tamanho do cluster de origem versus cluster de destino*: o número de nós e o tipo de nó para os quais é possível redimensionar com redimensionamento elástico são determinados pelo número de nós no cluster de origem e o tipo de nó escolhido para o cluster redimensionado. Para determinar as possíveis configurações disponíveis, você pode usar o console. Ou você pode usar o comando `describe-node-configuration-options` da AWS CLI com a opção `action-type resize-cluster`. Para obter mais informações sobre o redimensionamento usando o console do Amazon Redshift, consulte [Redimensionamento de um cluster](#resizing-cluster). 

  O exemplo de comando CLI a seguir descreve as opções de configuração disponíveis. Neste exemplo, o cluster chamado `mycluster` é um cluster `dc2.large` de 8 nós.

  ```
  aws redshift describe-node-configuration-options --cluster-identifier mycluster --region eu-west-1 --action-type resize-cluster
  ```

  Este comando retorna uma lista de opções com os tipos de nós, o número de nós e a utilização do disco recomendados para cada opção. As configurações retornadas podem variar de acordo com o cluster de entrada específico. Você pode escolher uma das configurações retornadas ao especificar as opções do comando CLI `resize-cluster`. 
+ *Teto nos nós adicionais* - O redimensionamento elástico tem limites nos nós que é possível adicionar a um cluster. Por exemplo, um cluster dc2 oferece suporte ao redimensionamento elástico até o dobro do número de nós. Para ilustrar, é possível adicionar um nó a um cluster dc2.8xlarge de 4 nós para torná-lo um cluster de 5 nós ou adicionar mais nós até atingir 8.
**nota**  
Os limites de crescimento e redução se baseiam no tipo de nó original e no número de nós do cluster original ou no redimensionamento clássico mais recente. Se um redimensionamento elástico exceder os limites de crescimento ou redução, use um redimensionamento clássico.

  Com alguns tipos de nó ra3, você pode aumentar o número de nós até quatro vezes a contagem existente. Especificamente, suponha que seu cluster consiste em nós ra3.4xlarge ou ra3.16xlarge. Em seguida, você pode usar o redimensionamento elástico para aumentar o número de nós em um cluster de 8 nós para 32. Ou você pode escolher um valor abaixo do limite. (Lembre-se de que a capacidade de aumentar o cluster em 4x depende do tamanho do cluster de origem.) Se o cluster tiver nós ra3.xlplus, o limite é duplo.

  Todos os tipos de nó ra3 suportam uma diminuição no número de nós para um quarto da contagem existente. Por exemplo, você pode diminuir o tamanho de um cluster com nós ra3.4xlarge de 12 nós para 3, ou para um número acima do mínimo.

  A tabela a seguir lista os limites de crescimento e redução para cada tipo de nó que oferece suporte ao redimensionamento elástico.    
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/redshift/latest/mgmt/resizing-cluster.html)
**nota**  
 **Escolher tipos de nós legados ao redimensionar um cluster RA3**: se você tentar redimensionar de um cluster com nós RA3 para outro tipo de nó, como DC2, uma mensagem de aviso de validação será exibida no console e a operação de redimensionamento não será concluída. Isso ocorre porque o redimensionamento para tipos de nós legados não é compatível. Isso evita que um cliente redimensione para um tipo de nó que está obsoleto ou prestes a ser descontinuado. Isso se aplica tanto ao redimensionamento elástico quanto ao redimensionamento clássico. 

## Classic resize (Redimensionamento clássico)
<a name="classic-resize-faster"></a>

O redimensionamento clássico lida com casos de uso em que a alteração no tamanho do cluster ou no tipo de nó não é compatível com o redimensionamento elástico. Quando você executa um redimensionamento clássico, o Amazon Redshift cria um cluster de destino e migra seus dados e metadados do cluster de origem para ele. 

### O redimensionamento clássico para RA3 pode fornecer melhor disponibilidade
<a name="classic-resize-improved"></a>

O redimensionamento clássico foi aprimorado quando o tipo de nó de destino é RA3. Isso é feito usando uma operação de backup e restauração entre o cluster de origem e de destino. Quando o redimensionamento começa, o cluster de origem é reiniciado e fica indisponível por alguns minutos. Depois disso, o cluster fica disponível para operações de leitura e gravação enquanto o redimensionamento continua em segundo plano.

#### Verificação do cluster
<a name="classic-resize-improved-considerations"></a>

Para garantir que você tenha o melhor desempenho e os melhores resultados ao realizar um redimensionamento clássico para um cluster RA3, preencha esta lista de verificação. Se você não seguir a lista de verificação, talvez não obtenha alguns dos benefícios do redimensionamento clássico com nós RA3, como a capacidade de realizar operações de leitura e gravação.

1. O tamanho dos dados deve estar abaixo de 2 petabytes. (Um petabyte é igual a 1.000 terabytes.) Para validar o tamanho dos dados, crie um snapshot e verifique o tamanho dele. Você também pode executar a seguinte consulta para verificar o tamanho: 

   ```
   SELECT
   sum(case when lower(diststyle) like ('%key%') then size else 0 end) distkey_blocks,
   sum(size) as total_blocks,
   ((distkey_blocks/(total_blocks*1.00)))*100 as Blocks_need_redist
   FROM svv_table_info;
   ```

   A tabela `svv_table_info` é visível somente para superusuários.

1. Antes de iniciar um redimensionamento clássico, é necessário ter um snapshot manual que tenha, no máximo, 10 horas. Caso você não tenha, crie um snapshot.

1. O snapshot usado para realizar o redimensionamento clássico não pode ser usado para uma restauração de tabela ou outra finalidade.

1. O cluster deve estar em uma VPC.

#### Operações de classificação e distribuição que resultam do redimensionamento clássico para RA3
<a name="classic-resize-effects"></a>

Durante o redimensionamento clássico para RA3, as tabelas com distribuição de chaves migradas como distribuição regular são reconvertidas no estilo de distribuição original. A duração disso depende do tamanho dos dados e da ocupação do cluster. As workloads de consulta têm maior prioridade para executar a migração de dados. Para obter mais informações, consulte [Estilos de distribuição](https://docs.aws.amazon.com/redshift/latest/dg/c_choosing_dist_sort.html). As leituras e gravações no banco de dados funcionam durante esse processo de migração, embora possa levar mais tempo para que as consultas sejam concluídas. No entanto, a escalabilidade da simultaneidade pode aumentar o desempenho durante esse momento adicionando recursos para workloads de consulta. Você pode consultar o andamento da migração de dados visualizando resultados das visualizações [SYS\$1RESTORE\$1STATE](https://docs.aws.amazon.com/redshift/latest/dg/SYS_RESTORE_STATE.html) e [SYS\$1RESTORE\$1LOG](https://docs.aws.amazon.com/redshift/latest/dg/SYS_RESTORE_LOG.html). Veja mais informações sobre o monitoramento a seguir.

Depois que o cluster é totalmente redimensionado, ocorre o seguinte comportamento de classificação:
+ Se o redimensionamento resultar em mais fatias no cluster, as tabelas de distribuição KEY ficarão parcialmente desclassificadas, mas as tabelas EVEN permanecerão classificadas. Além disso, as informações sobre a quantidade de dados classificados podem não estar atualizadas, diretamente após o redimensionamento. Após a recuperação da chave, a limpeza automática classifica a tabela ao longo do tempo.
+ Se o redimensionamento resultar em menos fatias no cluster, as tabelas de distribuição KEY e EVEN ficarão parcialmente sem classificação. A limpeza automática classifica a tabela ao longo do tempo.

Para obter mais informações sobre a limpeza automática de tabelas, consulte [Vacuum de tabelas](https://docs.aws.amazon.com/redshift/latest/dg/t_Reclaiming_storage_space202.html). Para obter mais informações sobre fatias em nós de computação, consulte [Arquitetura do sistema de data warehouse](https://docs.aws.amazon.com/redshift/latest/dg/c_high_level_system_architecture.html).

#### Etapas clássicas de redimensionamento quando o cluster de destino é RA3
<a name="classic-resize-stages-ra3"></a>

O redimensionamento clássico consiste nas seguintes etapas, quando o tipo de cluster de destino é RA3 e você atende aos pré-requisitos detalhados na seção anterior.

1. A migração inicia do cluster de origem para o cluster de destino. Quando o cluster é provisionado, o Amazon Redshift envia uma notificação de evento de que o redimensionamento foi iniciado. Ele reinicia o cluster existente, que encerra todas as conexões. Se o cluster existente for um cluster produtor de unidade de compartilhamento de dados, as conexões com clusters de consumidores também serão fechadas. A reinicialização leva alguns minutos. 

1. Após a reinicialização, o banco de dados fica disponível para leitura e gravação. Além disso, a unidade de compartilhamento de dados é retomada, o que leva mais alguns minutos.

1. Os dados são migrados para o cluster de destino. Quando o tipo de nó de destino é RA3, as leituras e gravações estão disponíveis durante a migração de dados.

1. Quando o processo de redimensionamento está quase concluído, o Amazon Redshift atualiza para o endpoint do cluster de destino e todas as conexões com o cluster de origem são descartadas. O cluster de destino se torna o produtor da unidade de compartilhamento de dados.

1. O redimensionamento é concluído. O Amazon Redshift envia uma notificação de evento.

Você pode ver o progresso do redimensionamento no console do Amazon Redshift. O tempo necessário para redimensionar um cluster depende da quantidade de dados. 

**nota**  
 **Escolher tipos de nós legados ao redimensionar um cluster RA3**: se você tentar redimensionar de um cluster com nós RA3 para outro tipo de nó, como DC2, uma mensagem de aviso de validação será exibida no console e a operação de redimensionamento não será concluída. Isso ocorre porque o redimensionamento para tipos de nós legados não é compatível. Isso evita que um cliente redimensione para um tipo de nó que está obsoleto ou prestes a ser descontinuado. Isso se aplica tanto ao redimensionamento elástico quanto ao redimensionamento clássico. 

#### Monitorar um redimensionamento clássico quando o cluster de destino é RA3
<a name="resize-monitoring"></a>

Para monitorar um redimensionamento clássico de um cluster provisionado em andamento, inclusive a distribuição de chaves, use [SYS\$1RESTORE\$1STATE](https://docs.aws.amazon.com/redshift/latest/dg/SYS_RESTORE_STATE.html). Isso mostra a porcentagem concluída da tabela que está sendo convertida. Você deve ser um superusuário para acessar os dados.

Elimine as tabelas desnecessárias ao realizar um redimensionamento clássico. Quando você faz isso, as tabelas existentes podem ser distribuídas mais rapidamente.

### Etapas clássicas de redimensionamento quando o cluster de destino não é RA3
<a name="classic-resize-stages"></a>

O redimensionamento clássico consiste no que se apresenta a seguir, quando o tipo de nó de destino é diferente de RA3, como DC2, por exemplo.

1. A migração inicia do cluster de origem para o cluster de destino. Quando o cluster é provisionado, o Amazon Redshift envia uma notificação de evento de que o redimensionamento foi iniciado. Ele reinicia o cluster existente, que encerra todas as conexões. Se o cluster existente for um cluster produtor de unidade de compartilhamento de dados, as conexões com clusters de consumidores também serão fechadas. A reinicialização leva alguns minutos.

   Observe que qualquer relação de banco de dados, como uma tabela ou visão materializada, criada com `BACKUP NO` não é retida durante o redimensionamento clássico. Para obter mais informações, consulte [CRIAR VISÃO MATERIALIZADA](https://docs.aws.amazon.com/redshift/latest/dg/materialized-view-create-sql-command.html).

1. Após a reinicialização, o banco de dados fica disponível somente para leitura. A unidade de compartilhamento de dados é retomada, o que leva mais alguns minutos.

1. Os dados são migrados para o cluster de destino. O banco de dados permanece somente para leitura.

1. Quando o processo de redimensionamento está quase concluído, o Amazon Redshift atualiza para o endpoint do cluster de destino e todas as conexões com o cluster de origem são descartadas. O cluster de destino se torna o produtor da unidade de compartilhamento de dados.

1. O redimensionamento é concluído. O Amazon Redshift envia uma notificação de evento.

Você pode ver o progresso do redimensionamento no console do Amazon Redshift. O tempo necessário para redimensionar um cluster depende da quantidade de dados.

**nota**  
Pode levar dias ou até semanas para redimensionar um cluster com uma grande quantidade de dados quando o cluster de destino não é RA3 ou não atende aos pré-requisitos de um cluster de destino RA3 detalhados na seção anterior.  
Observe também que a capacidade de armazenamento usada para o cluster pode aumentar após um redimensionamento clássico. Esse é o comportamento normal do sistema quando o cluster tem fatias de dados adicionais resultantes do redimensionamento clássico. Esse uso de capacidade adicional pode ocorrer mesmo quando o número de nós no cluster permanece o mesmo.

### Redimensionamento elástico versus redimensionamento clássico
<a name="classic-resize-vs-classic-resize"></a>

A tabela a seguir compara o comportamento entre os dois tipos de redimensionamento.


| Comportamento | Elastic resize (Redimensionamento elástico) | Classic resize (Redimensionamento clássico) | Comentários | 
| --- | --- | --- | --- | 
| Retenção de dados do sistema | O redimensionamento elástico retém os dados de log do sistema. | O redimensionamento clássico não retém tabelas e dados do sistema. | Se você habilitou o registro em log de auditoria em seu cluster de origem, poderá continuar a acessar os logs no Amazon S3 ou no CloudWatch após um redimensionamento. Você pode manter ou excluir esses conforme a especificação das políticas de dados. | 
| Alteração nos tipos de nó | Redimensionamento elástico quando o tipo de nó não muda: o redimensionamento no local e a maioria das consultas são mantidos. Redimensionamento elástico, com um novo tipo de nó selecionado: um novo cluster é criado. As consultas são descartadas à medida que o processo de redimensionamento é concluído. | Redimensionamento clássico: um novo cluster é criado. As consultas são descartadas durante o processo de redimensionamento. |  | 
| Retenção de sessão e consulta | O redimensionamento elástico retém sessões e consultas quando o tipo de nó é o mesmo no cluster de origem e de destino. Se você escolher um novo tipo de nó, as consultas serão descartadas. | O redimensionamento clássico não retém sessões e consultas. As consultas são descartadas. | Quando as consultas são descartadas, é possível esperar uma degradação no desempenho. É melhor realizar uma operação de redimensionamento durante um período de uso leve. | 
| Cancelar operação de redimensionamento | Não é possível cancelar um redimensionamento elástico. | Você pode cancelar uma operação de redimensionamento clássico antes de ser concluída, escolhendo **Cancelar redimensionamento** nos detalhes do cluster no console do Amazon Redshift.  | A quantidade de tempo necessária para cancelar um redimensionamento depende do estágio da operação de redimensionamento durante o cancelamento. Quando você fizer isso, cluster não estará disponível até que a operação de redimensionamento de cancelamento seja concluída. Se a operação de redimensionamento estiver no estágio final, não será possível cancelá-la. Não é possível cancelar o redimensionamento clássico para um cluster RA3. | 

### Programar um redimensionamento
<a name="rs-restore-resize-overview-schedule"></a>

É possível programar operações de redimensionamento para aumentar a escala verticalmente do cluster a fim de antecipar o alto uso ou para reduzir a escala verticalmente do cluster a fim de economizar custos. O agendamento funciona tanto para redimensionamento elástico quanto para redimensionamento clássico. Agora é possível configurar uma programação no console do Amazon Redshift. Para obter mais informações, consulte [Redimensionamento de um cluster](#resizing-cluster), em **Gerenciamento de clusters usando o console**. Também é possível usar as operações da API do Amazon Redshift ou de AWS CLI para programar um redimensionamento. Para obter mais informações, consulte [create-scheduled-action](https://docs.aws.amazon.com/cli/latest/reference/redshift/create-scheduled-action.html) na *Referência de comandos da AWS CLI* ou [CreateScheduledAction](https://docs.aws.amazon.com/redshift/latest/APIReference/API_CreateScheduledAction.html) na *Referência da API do Amazon Redshift*.

### Snapshot, restauração e redimensionamento
<a name="rs-tutorial-snapshot-restore-resize-overview"></a>

O [redimensionamento elástico](#elastic-resize) é o método mais rápido para redimensionar um cluster do Amazon Redshift. Se o redimensionamento elástico não for uma opção para você e precisar de acesso de gravação quase constante ao cluster, use as operações snapshot e redimensionamento clássico descritas na seção a seguir. Essa abordagem requer que todos os dados gravados no cluster de origem depois do snapshot ter sido feito devam ser copiados manualmente para o cluster de destino após a mudança. Dependendo do tempo que a cópia leva, você pode precisar repetir isso várias vezes até que tenha os mesmos dados em ambos os clusters. Depois, é possível fazer a mudança para o cluster de destino. Esse processo poderá ter um impacto negativo sobre consultas existentes até o conjunto de dados completo estar disponível no cluster de destino. No entanto, minimiza o tempo que você não pode gravar no banco de dados. 

A abordagem de snapshot, restauração e redimensionamento clássico usa o seguinte processo: 

1. Faça um snapshot do cluster existente. O cluster existente é o cluster de origem. 

1. Observe a hora em que o snapshot foi tirado. Fazer isso significa que você pode identificar depois o ponto em que precisará reexecutar novamente os processos Extract, Transform, Load (ETL – Extração, transformação, carga) para carregar dados pós-snapshot no banco de dados de destino. 

1. Restaure o snapshot em um novo cluster. Este novo cluster é o cluster de destino. Verifique se os dados de exemplo estão no cluster de destino. 

1. Redimensione o cluster de destino. Selecione o novo tipo de nó, o número de nós e outras configurações do cluster de destino. 

1. Revise as cargas dos processos ETL ocorridos depois que você tiver feito um snapshot do cluster de origem. Certifique-se de recarregar os mesmos dados na mesma ordem no cluster de destino. Se tiver cargas de dados em andamento, repita esse processo várias vezes até os dados serem iguais nos clusters de origem e de destino. 

1. Pare todas as consultas em execução no cluster de origem. Para isso, reinicie o cluster ou faça login como um superusuário e use os comandos [PG\$1CANCEL\$1BACKEND](https://docs.aws.amazon.com/redshift/latest/dg/PG_CANCEL_BACKEND.html) e [PG\$1TERMINATE\$1BACKEND](https://docs.aws.amazon.com/redshift/latest/dg/PG_TERMINATE_BACKEND.html). Recarregar o cluster é a maneira mais fácil de verificar se o cluster está indisponível. 

1. Renomeie o cluster de origem. Por exemplo, renomeie-o de `examplecluster` para `examplecluster-source`. 

1. Renomeie o cluster de destino para usar o cluster de origem antes de renomeá-lo. Por exemplo, renomeie o cluster de destino do anterior para `examplecluster`. Deste ponto em diante, todos os aplicativos que usarem o endpoint contendo `examplecluster` se conectarão ao cluster de destino. 

1. Exclua o cluster de origem depois de alternar para o cluster de destino e verifique se todos os processos funcionam conforme esperado. 

Como alternativa, você pode renomear os clusters de origem e de destino antes de recarregar dados no cluster de destino. Essa abordagem funciona se você não exigir que todos os sistemas e relatórios dependentes sejam atualizados imediatamente com eles para o cluster de destino. Nesse caso, a etapa 6 será movida para o final do processo descrito anteriormente. 

O processo rename somente será necessário se você quiser que os aplicativos continuem usando o mesmo endpoint para se conectar ao cluster. Se não precisar disso, você poderá atualizar todos os aplicativos que se conectarem ao cluster para usar o endpoint do cluster de destino sem renomear o cluster. 

Existem alguns benefícios em reutilizar um nome de cluster. Primeiro, você não precisa atualizar strings de conexão do aplicativo porque o endpoint não muda, mesmo que o cluster subjacente mude. Em segundo lugar, itens relacionados, como alarmes do Amazon CloudWatch e notificações do Amazon Simple Notification Service (Amazon SNS) estão associados ao nome do cluster. Essa associação significa que você pode continuar usando os mesmos alarmes e notificações configurados para o cluster. Esse uso continuado é basicamente uma preocupação em ambientes de produção nos quais você deseja a flexibilidade para redimensionar o cluster sem reconfigurar itens relacionados, como alarmes e notificações. 

# Renomear um cluster
<a name="rs-mgmt-rename-cluster"></a>

Você pode renomear um cluster se quiser que ele use um nome diferente. Como o endpoint para seu cluster inclui o nome do cluster (também referido como o *identificador do cluster*), o endpoint altera para usar o novo nome após a conclusão da renomeação. Por exemplo, se você tiver um cluster chamado `examplecluster` e renomeá-lo para `newcluster`, o endpoint altera para usar o identificador `newcluster`. Todos os aplicativos que se conectam ao cluster devem ser atualizados com o novo endpoint. 

Você poderá renomear um cluster se quiser alterar o cluster aos quais suas aplicações se conectam sem ter que mudar o endpoint nessas aplicações. Nesse caso, você deve primeiro renomear o cluster original e, em seguida, alterar o segundo cluster a fim de reutilizar o nome do cluster original antes da renomeação. Fazer isso é necessário, pois o identificador do cluster deve ser exclusivo em sua conta e região, portanto o cluster original e segundo cluster não podem ter o mesmo nome. Você pode fazer isso se restaurar um cluster de um snapshot e não quiser alterar as propriedades de conexão de nenhum aplicativo dependente. 

**nota**  
 Se você excluir o cluster original, será responsável pela exclusão de todos os snapshots de cluster indesejados. 

Quando você renomeia um cluster, o status do cluster muda para `renaming` até que o processo seja concluído. O nome DNS antigo que era usado pelo cluster é excluído imediatamente, embora ele possa permanecer armazenado em cache por alguns minutos. O novo nome DNS do cluster renomeado entra em vigor dentro de, aproximadamente, 10 minutos. O cluster renomeado não fica disponível até que o novo nome entre em vigor. O cluster será reinicializado e todas as conexões existentes com cluster serão encerradas. Após a conclusão, o endpoint será alterado para usar o novo nome. Por este motivo, você deve interromper a execução de consultas antes de iniciar a renomeação e reiniciá-las após sua conclusão. 

 Snapshots do cluster são retidos e todos os snapshots associados a um cluster permanecem associados a esse cluster após a renomeação. Por exemplo, suponha que você tenha um cluster que atenda ao seu banco de dados de produção e tenha vários snapshots. Se você renomear o cluster e substituí-lo no ambiente de produção com um snapshot, o cluster que você renomeou ainda terá esses snapshots existentes associados a ele. 

 Os alarmes do Amazon CloudWatch e as notificações de evento do Amazon Simple Notification Service (Amazon SNS) estão associados ao nome do cluster. Se você renomear o cluster, precisará atualizá-los apropriadamente. Você pode atualizar os alarmes do CloudWatch no console do CloudWatch e atualizar as notificações de eventos do Amazon SNS no console do Amazon Redshift no painel de **Eventos**. Os dados de carregamento e consulta do cluster continuam a exibir dados de antes e depois da renomeação. Contudo, os dados de performance são reiniciados após a conclusão do processo de renomeação. 

Para obter mais informações, consulte [Modificar um cluster](modify-cluster.md).

# Atualizar a versão de um cluster
<a name="upgrade-release-version-cluster"></a>

É possível atualizar a versão de manutenção de um cluster que tem um valor **Release Status (Status da versão)** de **New release available (Nova versão disponível)**. Ao atualizar a versão de manutenção, você pode optar por atualizar imediatamente ou atualizar na próxima janela de manutenção.

**Importante**  
Se você atualizar imediatamente, o cluster ficará offline até que a atualização seja concluída.

**Para atualizar um cluster para uma nova versão**

1. Faça login no Console de gerenciamento da AWS e abra o console do Amazon Redshift em [https://console.aws.amazon.com/redshiftv2/](https://console.aws.amazon.com/redshiftv2/).

1. No menu de navegação, escolha **Clusters**. 

1. Escolha o cluster a ser atualizado 

1. Em **Actions (Ações)**, escolha **Upgrade cluster version (Atualizar versão de cluster)**. A página **Upgrade cluster version (Atualizar versão de cluster)** é exibida.

1. Siga as instruções na página. 

1. Escolha **Upgrade cluster version (Atualizar versão de cluster)**. 

# Pausar e retomar um cluster
<a name="rs-mgmt-pause-resume-cluster"></a>

Se você tiver um cluster que só precisa estar disponível em horários específicos, poderá pausar o cluster e retomá-lo posteriormente. Enquanto o cluster estiver pausado, o faturamento sob demanda ficará suspenso. Somente o armazenamento do cluster gerará cobranças. Para obter informações sobre preço, consulte [a página de preço do Amazon Redshift](https://aws.amazon.com/redshift/pricing/). 

Quando você pausa um cluster, o Amazon Redshift cria um snapshot, começa a encerrar as consultas e coloca o cluster em um estado de pausa. Se você excluir um cluster pausado sem solicitar um snapshot final, não será possível restaurar o cluster. Não é possível cancelar ou reverter uma pausa ou retomar a operação após ser iniciada. 

Você pode pausar e retomar um cluster usando o console do Amazon Redshift, a AWS CLI ou as operações da API do Amazon Redshift. 

Você pode agendar ações para pausar e retomar um cluster. Ao usar o novo console do Amazon Redshift para criar uma programação recorrente para pausar e retomar, duas ações programadas são criadas para o intervalo de datas que você escolher. Os nomes das ações agendadas recebem os sufixos `-pause` e `-resume`. O comprimento total do nome deve caber no tamanho máximo de um nome de ação planejada. 

Não é possível pausar os seguintes tipos de clusters: 
+ Clusters do EC2-Classic. 
+ Clusters que não estão ativos, por exemplo, um cluster que está sendo modificado atualmente. 
+ Clusters do Hardware security module (HSM – Módulo de segurança de hardware) 
+ Clusters com snapshots automatizados desativados. 

Ao decidir pausar um cluster, considere o seguinte: 
+ Conexões ou consultas do cluster ficam indisponíveis.
+ Você não pode ver as informações de monitoramento de consulta de um cluster pausado no console do Amazon Redshift. 
+ Não é possível modificar um cluster pausado. Nenhuma das ações agendadas no cluster será realizada. Isso inclui a criação de snapshots, o redimensionamento de clusters e as operações de manutenção do cluster. 
+ Métricas de hardware não são criadas. Atualize seus alarmes CloudWatch se você tiver alarmes definidos em métricas ausentes. 
+ Não é possível copiar os snapshots automatizados mais recentes de um cluster pausado para snapshots manuais. 
+ Enquanto um cluster estiver pausado, ele não poderá ser retomado enquanto a operação de pausa não for concluída. 
+ Ao pausar um cluster, o faturamento fica suspenso. No entanto, a operação de pausa normalmente é concluída em 15 minutos, dependendo do tamanho do cluster. 
+ Os logs de auditoria são arquivados e não são restaurados na retomada. 
+ Depois que um cluster é pausado, pode ser que não haja rastreamentos e logs disponíveis para solucionar problemas que ocorreram antes da pausa. 
+  Se você estiver gerenciando as credenciais de administrador usando AWS Secrets Manager e pausar o cluster, o segredo do cluster não será excluído e você continuará recebendo a cobrança pelo segredo. Para obter mais informações sobre como gerenciar a senha de administrador do Redshift com o AWS Secrets Manager, consulte [Gerenciamento das senhas de administrador do Amazon Redshift usando AWS Secrets Manager](redshift-secrets-manager-integration.md). 
+ As tabelas sem backup no cluster não são restauradas na retomada no caso de tipos de instância RA3. Elas não são restauradas na retomada para tipos de instância do DC2. Para ter mais informações sobre tabelas sem backup, consulte [Excluir tabelas de snapshots](working-with-snapshots.md#snapshots-no-backup-tables).

Ao retomar um cluster, considere o seguinte: 
+ A versão do cluster retomado é atualizada para a versão de manutenção com base na janela de manutenção do cluster. 
+ Se você excluir a sub-rede associada a um cluster pausado, poderá ter uma rede incompatível. Nesse caso, restaure o cluster do snapshot mais recente. 
+ Se você excluir um endereço IP elástico enquanto o cluster estiver pausado, um novo endereço IP elástico será solicitado. 
+ Se o Amazon Redshift não puder retomar o cluster com sua interface de rede elástica anterior, o Amazon Redshift tenta alocar uma nova. 
+ Ao retomar um cluster, os endereços IP do nó podem mudar. Pode ser necessário atualizar suas configurações de VPC para oferecer suporte a esses novos endereços IP para recursos como COPY from Secure Shell (SSH) ou COPY from Amazon EMR.
+ Se você tentar retomar um cluster que não está pausado, a operação de retomada retornará um erro. Se a operação de retomada fizer parte de uma ação agendada, modifique ou exclua a ação agendada para evitar erros futuros. 
+ Dependendo do tamanho do cluster, pode demorar vários minutos para retomar o cluster antes que as consultas possam ser processadas. Além disso, a performance da consulta pode ser afetado durante um período, enquanto o cluster passa por reidratação após a conclusão da retomada. 

# Reinicialização de um cluster
<a name="reboot-cluster"></a>

A reinicialização de cluster é uma operação que reinicia o cluster com a mesma configuração anterior à reinicialização. Você pode reinicializar um cluster para aplicar atualizações de manutenção pendentes, redefinir alterações de configuração, recuperar-se de determinados problemas ou solucionar problemas do cluster. A reinicialização de cluster pode ajudar a garantir a performance, a segurança e a estabilidade ideais do ambiente do Amazon Redshift. O procedimento a seguir apresenta etapas detalhadas para reinicializar um cluster do Amazon Redshift.

Quando você reinicializa um cluster, o status do cluster é definido como `rebooting` e um evento de cluster será criado quando a reinicialização for concluída. Todas as modificações pendentes do cluster são aplicadas nesta reinicialização.

**Para reinicializar um cluster**

1. Faça login no Console de gerenciamento da AWS e abra o console do Amazon Redshift em [https://console.aws.amazon.com/redshiftv2/](https://console.aws.amazon.com/redshiftv2/).

1. No menu de navegação, escolha **Clusters**. 

1. Escolha o cluster a ser reiniciado. 

1. Em **Actions (Ações)**, escolha **Reboot cluster (Reiniciar cluster)**. A página **Reboot cluster (Reinicializar cluster)** é exibida.

1. Escolha**Reboot cluster (Reinicializar cluster)**. 

# Realocar um cluster
<a name="managing-cluster-recovery"></a>

Usando a *realocação* no Amazon Redshift, você permite que o Amazon Redshift mova um cluster para outra zona de disponibilidade (AZ) sem perda de dados ou alterações em suas aplicações. Com a realocação, você pode continuar as operações quando houver uma interrupção do serviço em seu cluster com impacto mínimo. 

Quando a realocação de cluster está ativada, o Amazon Redshift pode optar por realocar clusters em algumas situações. Em particular, isso acontece quando os problemas na zona de disponibilidade atual impedem a operação ideal do cluster ou melhoram a disponibilidade do serviço. Você também pode chamar a função de realocação nos casos em que restrições de recursos em uma determinada zona de disponibilidade estão interrompendo as operações de cluster. Um exemplo é a capacidade de retomar ou redimensionar um cluster. O Amazon Redshift oferece o recurso de realocação sem custo adicional.

Quando um cluster do Amazon Redshift é realocado para uma nova zona de disponibilidade, o novo cluster tem o mesmo endpoint que o cluster original. Suas aplicações podem se reconectar ao endpoint e continuar as operações sem modificações ou perda de dados. No entanto, a realocação pode nem sempre ser possível devido a potenciais restrições de recursos em uma determinada zona de disponibilidade.

A realocação do cluster do Amazon Redshift só é possível com os tipos de instância RA3. Os tipos de instância RA3 usam o Redshift Managed Storage (RMS) como uma camada de armazenamento durável. A cópia mais recente dos dados de um cluster está sempre disponível em outras zonas de disponibilidade em uma região da AWS. Em outras palavras, você pode realocar um cluster do Amazon Redshift para outra zona de disponibilidade sem perda de dados. 

Quando você ativa a realocação para um cluster, o Amazon Redshift migra o cluster para que fique atrás de um proxy. Isso ajuda a implementar o acesso independente de localização aos recursos de computação em cluster. A migração faz com que o cluster seja reinicializado. Quando um cluster é realocado para outra zona de disponibilidade, ocorre uma interrupção enquanto o novo cluster é colocado online novamente na nova zona de disponibilidade. No entanto, você não precisa fazer alterações em suas aplicações porque o endpoint do cluster permanece inalterado mesmo depois que o cluster é realocado para a nova zona de disponibilidade. 

A realocação de clusters é habilitada por padrão em clusters RA3 recém-criados ou restaurados cujo grupo de sub-redes inclua várias zonas de disponibilidade. O Amazon Redshift atribui 5439 como porta padrão ao criar um cluster provisionado. Você pode mudar para outra porta do intervalo de portas 5431–5455 ou 8191–8215. (Não mude para uma porta fora dos intervalos. Isso resulta em um erro.) Para alterar a porta padrão de um cluster provisionado, use o console do Amazon Redshift, a AWS CLI ou a API do Amazon Redshift. Para alterar a porta padrão de um grupo de trabalho sem servidor, use a AWS CLI ou a API do Amazon Redshift sem servidor.

Se você ativar a realocação e estiver usando o endereço IP do nó líder para acessar o cluster ou o roteamento aprimorado da VPC, deverá alterar esse acesso. Em vez disso, use o endereço IP associado ao endpoint da Virtual Private Cloud (VPC) do cluster. Para localizar esse endereço IP de cluster, localize e use o endpoint da VPC na seção **Rede e segurança** da página de detalhes do cluster. Para obter mais detalhes sobre o endpoint da VPC, faça login no console da Amazon VPC. 

Você também pode usar o comando `describe-vpc-endpoints` da AWS Command Line Interface(AWS CLI) para obter a interface de rede elástica associada ao endpoint. Você pode usar o comando `describe-network-interfaces` para obter o endereço IP associado. Para obter mais informações sobre os comandos da AWS CLI do Amazon Redshift, consulte [Comandos disponíveis](https://docs.aws.amazon.com/cli/latest/reference/redshift/index.html) na *Referência de comandos da AWS CLI*. 

## Limitações
<a name="limitations-recovery"></a>

Ao usar a realocação do Amazon Redshift, esteja ciente das seguintes limitações:
+ A realocação de cluster pode não ser possível em todos os cenários devido a potenciais limitações de recursos em uma determinada zona de disponibilidade. Se isso acontecer, o Amazon Redshift não alterará o cluster original.
+ A realocação não é compatível com as famílias de instâncias de produtos DC2.
+ Você não pode realizar uma realocação entre regiões da AWS.
+ O padrão de realocação do Amazon Redshift é a porta número 5439. Você também pode mudar para outra porta nos intervalos 5431-5455 ou 8191-8215.

## Gerenciar a realocação usando o console
<a name="cluster-recovery-console"></a>

Você pode gerenciar as configurações de realocação de cluster usando o console do Amazon Redshift.

### Desativar a realocação ao criar um cluster
<a name="enable-relocate-new-cluster."></a>

Use o procedimento a seguir para desativar a realocação ao criar um cluster. 

**Como desativar a realocação para um novo cluster**

1. Faça login no Console de gerenciamento da AWS e abra o console do Amazon Redshift em [https://console.aws.amazon.com/redshiftv2/](https://console.aws.amazon.com/redshiftv2/).

1. No menu de navegação, escolha **Clusters**. 

1. Escolha **Create cluster** (Criar cluster) para criar um novo cluster. Consulte mais informações sobre como criar um cluster em [Clusters provisionados do Amazon Redshift](https://docs.aws.amazon.com/redshift/latest/gsg/new-user.html) no *Guia de conceitos básicos do Amazon Redshift*.

1. Under **Backup**, for **Realocação de cluster**, escolha **Desabilitado**. Por padrão, a realocação está ativada.

1. Selecione **Create cluster** (Criar cluster).

### Modificar a realocação de um cluster existente
<a name="modify-relocate-cluster."></a>

Use o procedimento a seguir para alterar a configuração de realocação para um cluster existente.

**Para modificar a configuração de realocação para um cluster existente**

1. Faça login no Console de gerenciamento da AWS e abra o console do Amazon Redshift em [https://console.aws.amazon.com/redshiftv2/](https://console.aws.amazon.com/redshiftv2/).

1. No menu de navegação, escolha **Clusters**. Os clusters de sua conta na região atual da AWS são listados. Um subconjunto de propriedades de cada cluster é exibido nas colunas na lista.

1. Escolha o nome do cluster que você deseja modificar na lista. A página de detalhes do cluster é exibida.

1. Escolha a guia **Manutenção** e, em seguida, na guia **Detalhes de backup** escolha **Editar**.

1. Em **Backup**, escolha **Habilitado**. Por padrão, a realocação está ativada. 

1. Escolha **Modify Cluster** (Modificar cluster).

### Realocar um cluster
<a name="relocate-cluster."></a>

Use o procedimento a seguir para realocar um cluster para outra zona de disponibilidade. Isso é especialmente útil quando você deseja testar sua configuração de rede em zonas de disponibilidade secundárias ou quando você está executando restrições de recursos na zona de disponibilidade atual. 

**Para realocar um cluster para outra zona de disponibilidade**

1. Faça login no Console de gerenciamento da AWS e abra o console do Amazon Redshift em [https://console.aws.amazon.com/redshiftv2/](https://console.aws.amazon.com/redshiftv2/).

1. No menu de navegação, escolha **Clusters**. Os clusters de sua conta na região atual da AWS são listados. Um subconjunto de propriedades de cada cluster é exibido nas colunas na lista.

1. Escolha o nome do cluster que você deseja mover da lista. A página de detalhes do cluster é exibida.

1. Em **Ações**, escolha **Realocar**. A página **Realocar cluster** é exibida.

1. (Opcional) Escolha uma **zona de disponibilidade**. Se você não escolher uma zona de disponibilidade, o Amazon Redshift escolherá uma para você.

O Amazon Redshift inicia a realocação e exibe o cluster como realocando. Após a conclusão da realocação, o status do cluster muda para disponível.

## Gerenciar a realocação usando a CLI do Amazon Redshift
<a name="cluster-recovery-cli"></a>

Você pode gerenciar as configurações para realocação de cluster usando a interface de linha de comando (CLI) da AWS

Com a AWS CLI, o comando de exemplo a seguir cria um cluster do Amazon Redshift chamado **mycluster** com a realocação ativada.

```
aws redshift create-cluster --cluster-identifier mycluster --number-of-nodes 2 --master-username enter a username --master-user-password enter a password --node-type ra3.4xlarge --port 5439 --no-availability-zone-relocation
```

Se o cluster atual estiver usando uma porta diferente, você precisará modificá-lo para usar a porta 5431-5455 ou 8191-8215 antes de tentar ativar a realocação. O padrão é 5439. O comando de exemplo a seguir modifica a porta caso seu cluster não use uma do intervalo fornecido.

```
aws redshift modify-cluster --cluster-identifier mycluster --port 5439
```

O comando de exemplo a seguir inclui o parâmetro availability-zone-relocation no cluster do Amazon Redshift.

```
aws redshift modify-cluster --cluster-identifier mycluster --availability-zone-relocation
```

O comando de exemplo a seguir desativa o parâmetro availability-zone-realocation no cluster do Amazon Redshift.

```
aws redshift modify-cluster --cluster-identifier mycluster --no-availability-zone-relocation
```

O comando de exemplo a seguir invoca a realocação no cluster do Amazon Redshift.

```
aws redshift modify-cluster --cluster-identifier mycluster --availability-zone us-east-1b
```

# Definir um limite de uso em um cluster
<a name="rs-mgmt-set-limit-cluster"></a>

É possível adicionar até quatro limites de uso para controlar o uso de cada um dos seguintes itens:
+  Escalabilidade simultânea. 
+  Otimizações automáticas executadas com recursos extras de computação. 
+  Uso do Redshift Spectrum. 
+  Compartilhamento de dados entre regiões. 

## Definir um limite de uso para um cluster provisionado
<a name="rs-mgmt-set-limit-cluster-proc"></a>

Abaixo é apresentado o procedimento para definir um limite de uso em um cluster provisionado:

**Como definir um limite de uso para um cluster**

1. Faça login no Console de gerenciamento da AWS e abra o console do Amazon Redshift em [https://console.aws.amazon.com/redshiftv2/](https://console.aws.amazon.com/redshiftv2/).

1. Acesse o cluster provisionado para o qual deseja definir um limite.

1.  Na página de detalhes do cluster, selecione **Gerencia limite de uso** no menu suspenso **Ações**. Também é possível selecionar a guia **Manutenção** de um cluster, rolar para baixo e selecionar **Criar limites de uso**. 

1.  Selecione **Adicionar limite** para o limite de uso que você deseja definir. É possível adicionar até quatro limites a um determinado recurso. 

1.  Defina um **período** para o limite de uso, que pode ser **diário**, **semanal** ou **mensal**. 

1.  Defina um **limite de uso**. 
   +  Para escalabilidade simultânea e otimizações automáticas executadas com limites extras de recursos de computação, o limite de uso refere-se ao tempo durante o qual o Amazon Redshift usa o recurso em um determinado período. Nesse caso, o limite de uso é definido em horas e minutos. 
   +  Para o Redshift Spectrum, o limite de uso refere-se à quantidade de dados verificados no Amazon S3. Nesse caso, o limite de uso é definido em terabytes (TB). 
   +  Para compartilhamento de dados entre regiões, o limite de uso refere-se à quantidade de dados transferidos entre a região de produtor e as regiões de consumidor que podem ser consultados pelos consumidores. Nesse caso, o limite de uso é definido em terabytes (TB). 

1.  Defina a **ação** que o Amazon Redshift deve realizar quando o cluster atingir o limite. Elas podem ser as seguintes: 
   +  **Registrar em log na tabela do sistema**: adiciona um registro à visualização do sistema [SYS\$1QUERY\$1HISTORY](https://docs.aws.amazon.com/redshift/latest/dg/SYS_QUERY_HISTORY.html). É possível consultar a coluna usage\$1limit nessa visualização para determinar se uma consulta excedeu o limite. 
   +  **Alerta**: usa o Amazon SNS para configurar assinaturas de notificação e enviar notificações se um limite for violado. É possível escolher um tópico existente do Amazon SNS ou criar outro ou prosseguir sem nenhum. 
   +  **Desabilitar recurso**: desabilita o recurso. Também é possível optar por usar o Amazon SNS para enviar uma notificação. Os usuários podem continuar usando o cluster para outras tarefas. 

   As duas primeiras ações são informativas, mas a última desativa o uso do recurso.

1.  Escolha **Salvar alterações** na parte inferior da página para salvar o limite. Se você definir mais de um limite de uma vez, todas elas serão salvas de uma vez ao escolher **Salvar alterações**. 

# Encerrar e excluir um cluster
<a name="rs-mgmt-shutdown-delete-cluster"></a>

Você pode desativar seu cluster se quiser impedir sua execução e a cobrança de taxas. Quando você desativa um cluster, você pode, opcionalmente, criar um snapshot final. Se você criar um snapshot final, o Amazon Redshift criará um snapshot manual do seu cluster antes de desligá-lo. Se você pretende disponibilizar um novo cluster com os mesmos dados e configuração daquele que você está excluindo, precisará de um snapshot manual. Usando um snapshot manual, você poderá restaurar o snapshot posteriormente e continuar usando o cluster. 

Se você não precisa mais do seu cluster e de seus dados, pode desativá-lo sem criar um snapshot final. Nesse caso, o cluster e os dados são excluídos permanentemente.

Mesmo que você desative seu cluster com um snapshot final manual, todos os snapshots automatizados associados ao cluster serão excluídos quando o cluster for desativado. Todos os snapshots manuais associados ao cluster são retidos. Quaisquer snapshots manuais que são retidos, incluindo o snapshot final opcional, são cobrados na taxa de armazenamento do Amazon Simple Storage Service se você não tiver outros clusters em execução ao desligar o cluster, ou se você exceder o armazenamento gratuito disponível que é fornecido para o seu executando clusters do Amazon Redshift. Para obter mais informações sobre o custo de armazenamento de snapshots, consulte a [página de preço do Amazon Redshift](https://aws.amazon.com/redshift/pricing/). 

A exclusão de um cluster também exclui todos os segredos do AWS Secrets Manager associados.

**Para excluir um cluster**

1. Faça login no Console de gerenciamento da AWS e abra o console do Amazon Redshift em [https://console.aws.amazon.com/redshiftv2/](https://console.aws.amazon.com/redshiftv2/).

1. No menu de navegação, escolha **Clusters**.

1. Escolha o cluster a ser excluído. 

1. Em **Ações**, escolha **Excluir**. A página **Delete cluster (Excluir cluster)** é exibida. 

1. Escolha **Delete Cluster (Excluir cluster)**. 

**nota**  
Quando você exclui um cluster e opta por criar um snapshot final, o Amazon Redshift interrompe a solicitação de exclusão caso uma operação de restauração esteja em andamento no cluster. Se isso ocorrer, você poderá excluir o cluster sem um snapshot final ou excluí-lo com um snapshot final após a conclusão da restauração. 

# Snapshots e backups do Amazon Redshift
<a name="working-with-snapshots"></a>

Snapshots são backups pontuais de um cluster. Existem dois tipos de snapshots: *automatizado* e *manual*. O Amazon Redshift armazena esses snapshots internamente no Amazon S3 usando uma conexão Secure Sockets Layer (SSL) criptografada. 

O Amazon Redshift tira automaticamente snapshots incrementais que rastreiam as alterações no cluster desde o snapshot automatizado anterior. Os snapshots automatizados retêm todos os dados necessários para restaurar um cluster a partir de um snapshot. Você pode criar uma programação de snapshot para controlar quando snapshots automatizados são tirados ou tirar um snapshot manual a qualquer momento.

Quando você restaura a partir de um snapshot, o Amazon Redshift cria um novo cluster e disponibiliza o novo cluster antes que todos os dados sejam carregados, para que você possa começar a consultar o novo cluster imediatamente. O cluster transmite dados sob demanda do snapshot em resposta a consultas ativas e carrega os dados restantes em segundo plano. 

Ao iniciar um cluster, você pode definir o período de retenção para snapshots automatizados e manuais. Você pode alterar o período de retenção padrão para snapshots automatizados e manuais, modificando o cluster. É possível alterar o período de retenção do snapshot manual ao criar o snapshot ou modificando o snapshot. 

Você pode monitorar o progresso de snapshots visualizando os detalhes do snapshot no Console de gerenciamento da AWS ou chamando [describe-cluster-snapshots](https://docs.aws.amazon.com/cli/latest/reference/redshift/describe-cluster-snapshots.html) na CLI ou a ação de API [DescribeClusterSnapshots](https://docs.aws.amazon.com/redshift/latest/APIReference/API_DescribeClusterSnapshots.html). Para um snapshot em andamento, eles exibem informações como o tamanho do snapshot incremental, a taxa de transferência, o tempo decorrido e o tempo estimado restante. 

Para garantir que seus backups estejam sempre disponíveis para o cluster, o Amazon Redshift armazena snapshots em um bucket do Amazon S3 do gerenciado internamente pelo Amazon Redshift. Para gerenciar cobranças de armazenamento, avalie de quantos dias você precisa para manter snapshots automatizados e configure o período de retenção de acordo. Exclua todos os snapshots manuais dos quais você não precisa mais. Para obter mais informações sobre o custo do armazenamento de backup, consulte a página de [Preços do Amazon Redshift](https://aws.amazon.com/redshift/pricing/). 

Também é possível criar e restaurar snapshots usando o AWS Backup, um serviço totalmente gerenciado que ajuda você a centralizar e automatizar a proteção de dados nos serviços da AWS, na nuvem e em ambientes on-premises. Para obter mais informações, consulte [Integração do AWS Backup com o Amazon Redshift](managing-aws-backup.md). Para ter informações sobre o AWS Backup, consulte [What is AWS Backup?](https://docs.aws.amazon.com/aws-backup/latest/devguide/whatisbackup.html) no *Guia do desenvolvedor do AWS Backup*. 

## Trabalhar com snapshots e backups no Amazon Redshift sem servidor
<a name="working-with-snapshots-serverless"></a>

O Amazon Redshift sem servidor, do mesmo modo que um cluster provisionado, permite que você faça um backup como uma representação pontual dos objetos e dos dados no namespace. Existem dois tipos de backup no Amazon Redshift sem servidor: snapshots criados manualmente e pontos de recuperação criados automaticamente pelo Amazon Redshift sem servidor. Você pode encontrar mais informações sobre como trabalhar com snapshots para o Amazon Redshift sem servidor em [Trabalhar com snapshots e pontos de recuperação](https://docs.aws.amazon.com/redshift/latest/mgmt/serverless-snapshots-recovery-points.html). 

Também é possível restaurar um snapshot de um cluster provisionado para um namespace sem servidor. Para obter mais informações, consulte [Restaurar um namespace com tecnologia sem servidor usando um snapshot](https://docs.aws.amazon.com/redshift/latest/mgmt/serverless-snapshot-restore.html).

## Snapshots automatizados
<a name="about-automated-snapshots"></a>

Quando snapshots automatizados são ativados para um cluster, o Amazon Redshift tira snapshots desse cluster periodicamente. Por padrão, o Amazon Redshift tira um snapshot a cada oito horas ou depois de cada 5 GB por nó de alterações de dados, o que ocorrer primeiro. Se o seu volume de dados for maior que 5 GB \$1 número de nós, o menor tempo entre a criação automatizada de snapshots será de 15 minutos. Você também pode criar uma programação de snapshot para controlar quando snapshots automatizados são tirados. Se você estiver usando cronogramas personalizados, o tempo mínimo entre os snapshots automatizados será de uma hora. Os snapshots automatizados são ativados por padrão quando você cria um cluster.

Os snapshots automatizados são excluídos ao final de um período de retenção. O período de retenção padrão é de um dia, mas você pode modificá-lo usando o console do Amazon Redshift ou programaticamente usando a API ou CLI do Amazon Redshift.

Para desativar snapshots automatizados, defina o período de retenção como zero. Se você desativar os snapshots automatizados, o Amazon Redshift para de tirar snapshots e exclui todos os snapshots automatizados existentes para o cluster. Não é possível desabilitar snapshots automatizados para tipos de nó RA3. Você pode definir um período de retenção automatizado do tipo de nó RA3 de 1 a 35 dias. 

Somente o Amazon Redshift pode excluir um snapshot automatizado; você não pode excluí-lo manualmente. O Amazon Redshift exclui snapshots automatizados no final do período de retenção de um snapshot, quando você desativa os snapshots automatizados para o cluster ou quando exclui o cluster. *O Amazon Redshift retém o snapshot automatizado mais recente até que você desabilite os snapshots automatizados ou exclua o cluster.*

Se quiser manter um snapshot automatizado por um período mais longo, você poderá criar uma cópia dele como um snapshot manual. O snapshot automatizado será mantido até o final do período de retenção, mas o snapshot manual correspondente será retido até você excluí-lo manualmente ou até o final do período de retenção.

## Programações de snapshots automatizados
<a name="automated-snapshot-schedules"></a>

Para controlar com precisão quando snapshots são tirados, você pode criar uma programação de snapshot e anexá-la a um ou mais clusters. Quando você modifica uma programação de snapshot, a programação é modificada para todos os clusters associados. Se um cluster não tem uma programação de snapshot anexada, o cluster usa a programação padrão de snapshot automatizado. 

Uma *programação de snapshot* é um conjunto de regras de programação. Você pode definir uma regra de programação simples com base em um intervalo especificado, como a cada 8 ou 12 horas. Você também pode adicionar regras para tirar snapshots em certos dias da semana, em horários específicos ou durante períodos específicos. As regras também podem ser definidas usando expressões cron semelhantes ao Unix 

## Formato da programação de snapshot
<a name="working-with-snapshot-scheduling"></a>

No console do Amazon Redshift, você pode criar uma programação de snapshot. Você pode anexar uma programação a um cluster para acionar a criação de um snapshot do sistema. Uma programação pode ser associada a vários clusters, e você pode criar várias definições cron em uma programação para acionar um snapshot.

Você pode definir uma programação para seus snapshots usando uma sintaxe cron. A definição dessas programações usa uma sintaxe [cron](http://en.wikipedia.org/wiki/Cron) modificada do tipo Unix. Especifique o horário em [Tempo Universal Coordenado (UTC)](http://en.wikipedia.org/wiki/Coordinated_Universal_Time). Você pode criar programações com frequência máxima de uma hora e precisão mínima de um minuto.

As expressões cron modificadas do Amazon Redshift têm 3 campos obrigatórios, separados por espaço em branco. 

**Sintaxe**

```
cron(Minutes Hours Day-of-month Month Day-of-week Year)
```


| **Campos** | **Valores** | **Curingas** | 
| --- | --- | --- | 
|  Minutos  |  0–59  |  , - \$1 /   | 
|  Horas  |  0–23  |  , - \$1 /   | 
|  Dia do mês  |  1–31  |  , - \$1 ? / L W  | 
|  Mês  |  1-12 ou JAN-DEZ  |  , - \$1 /  | 
|  Dia da semana  |  1-7 ou SUN-SAT  |  , - \$1 ? L \$1  | 
|  Ano  |  1970–2199  |  , - \$1 /  | 

**Curingas**
+ A **,** (vírgula) curinga inclui valores adicionais. No campo `Day-of-week`, `MON,WED,FRI` incluirá segunda-feira, quarta-feira e sexta-feira. Os valores totais são limitados a 24 por campo.
+ O **-** (traço) curinga especifica intervalos. No campo `Hour`, 1–15 incluiria as horas 1 a 15 do dia especificado.
+ O **\$1** (asterisco) curinga inclui todos os valores no campo. No campo `Hours`, **\$1** incluirá cada hora.
+ A **/** (barra) curinga especifica incrementos. No campo `Hours`, você pode inserir **1/10** para especificar a cada décima hora, a partir da primeira hora do dia (por exemplo, 01:00, 11:00 e 21:00).
+ O curinga **?** (interrogação) especifica um ou outro. No campo `Day-of-month`, você pode inserir **7** e, se não se importar com qual dia da semana era o sétimo, pode inserir **?** no campo Dia da semana.
+ O curinga **L** nos campos `Day-of-month` ou `Day-of-week` especifica o último dia do mês ou da semana.
+ O curinga **W** no campo `Day-of-month` especifica um dia da semana. No campo `Day-of-month`, `3W` especifica o dia mais próximo do terceiro dia da semana do mês.
+ O curinga **\$1** no campo Dia da semana especifica uma determinada instância do dia da semana definido dentro de um mês. Por exemplo, 3\$12 seria a segunda terça-feira do mês: o 3 refere-se a terça-feira, porque é o terceiro dia de cada semana, e o 2 refere-se ao segundo dia desse tipo dentro do mês.
**nota**  
Se você usar um caractere “\$1”, poderá definir apenas uma expressão no campo do dia da semana. Por exemplo, "3\$11,6\$13" não é válido porque é interpretado como duas expressões. 

**Limites**
+ Não é possível especificar os campos `Day-of-month` e `Day-of-week` na mesma expressão cron. Se você especificar um valor em um dos campos, deverá usar um **?** (ponto de interrogação) no outro.
+ Os cronogramas de snapshot não são compatíveis com as seguintes frequências: 
  + Snapshots programados com frequência superior a 1 por hora.
  + Snapshots programados com frequência inferior a 1 por dia (24 horas).

  Se você tem programações sobrepostas que resultam na programação de snapshots em uma janela de 1 hora, o resultado é um erro de validação.

Ao criar uma programação, você pode usar os seguintes exemplos de strings cron.


| Minutos | Horas | Dia da semana | Significado | 
| --- | --- | --- | --- | 
|  0  |  14-20/1  |  TER  |  A cada hora entre 14h e 20h na terça-feira.  | 
|  0  |  21  |  SEG-SEX  |  Todas as noites, às 21h, de segunda a sexta-feira.  | 
|  30  |  0/6  |  SÁB-DOM  |  Incremento a cada 6 horas no sábado e domingo, a partir de 30 minutos após meia-noite (00:30) daquele dia. Isso resulta em um snapshot às [00:30, 06:30, 12:30 e 18:30] de cada dia.  | 
|  30  |  12/4  |  \$1  |  Incremento a cada 4 horas, a partir de 12:30 de cada dia. O resultado é [12:30, 16:30, 20:30].  | 

Por exemplo, para executar em uma programação de um incremento a cada 2 horas, a partir de 15:15 de cada dia. O resultado é [15:15, 17:15, 19:15, 21:15, 23:15] , especifique:

```
cron(15 15/2 *)   
```

Você pode criar várias definições de programação cron em uma programação. Por exemplo, o seguinte comando da AWS CLI contém duas programações cron em uma programação.

```
create-snapshot-schedule --schedule-identifier "my-test" --schedule-definition "cron(0 17 SAT,SUN)" "cron(0 9,17 MON-FRI)"   
```

## Snapshots manuais
<a name="about-manual-snapshots"></a>

Você poderá obter um snapshot manual a qualquer momento. Por padrão, os snapshots manuais são retidos indefinidamente, mesmo depois que você exclui o cluster. Você pode especificar o período de retenção ao criar um snapshot manual ou pode alterar o período de retenção modificando o snapshot. Para obter mais informações sobre como alterar o período de retenção, consulte [Modificar o período de retenção de snapshots manuais](snapshot-manual-retention-period.md).

Se um snapshot for excluído, você não poderá iniciar operações novas que referenciem esse snapshot. Porém, se estiver em andamento, uma operação de restauração será executada até a conclusão. 

O Amazon Redshift tem uma cota que limita o número total de snapshots manuais que você pode criar; esta cota é por conta da AWS por região da AWS. A cota padrão está listada em [Cotas e limites no Amazon Redshift](amazon-redshift-limits.md). 

## Armazenamento de snapshots
<a name="managing-snapshot-storage"></a>

Como os snapshots acumulam encargos de armazenamento, é importante que você os exclua quando não precisar mais deles. O Amazon Redshift exclui snapshots automatizados e manuais no final de seus respectivos períodos de retenção de snapshots. Você também pode excluir snapshots manuais usando o Console de gerenciamento da AWS ou com o comando da CLI [batch-delete-cluster-snapshots](https://docs.aws.amazon.com/cli/latest/reference/redshift/batch-delete-cluster-snapshots.html). 

É possível alterar o período de retenção do snapshot manual modificando as configurações do snapshot manual. 

Você pode obter informações sobre quanto armazenamento seus snapshots estão consumindo usando o console do Amazon Redshift ou usando o comando da CLI [describe-storage](https://docs.aws.amazon.com/cli/latest/reference/redshift/describe-storage.html). 

## Excluir tabelas de snapshots
<a name="snapshots-no-backup-tables"></a>

Por padrão, todas as tabelas permanentes definidas pelo usuário são incluídas em snapshots. Se uma tabela, como uma tabela temporária, não precisar de backup, você poderá reduzir significativamente o tempo necessário para criar snapshots e restaurá-los. Você também reduz o espaço de armazenamento no Amazon S3 usando uma tabela sem backup. Para criar uma tabela sem backup, inclua o parâmetro BACKUP NO ao criar a tabela. Para obter mais informações, consulte [CREATE TABLE](https://docs.aws.amazon.com/redshift/latest/dg/r_CREATE_TABLE_NEW.html) e [CREATE TABLE AS](https://docs.aws.amazon.com/redshift/latest/dg/r_CREATE_TABLE_AS.html) no *Guia do desenvolvedor de banco de dados do Amazon Redshift*.

**nota**  
Tabelas sem backup não são aceitas em clusters provisionados com RA3 e grupos de trabalho do Amazon Redshift sem servidor. Uma tabela marcada como sem backup em um cluster do RA3 ou um grupo de trabalho sem servidor será tratada como uma tabela permanente da qual sempre será feito backup durante a criação de um snapshot e sempre restaurada quando ocorrer a restauração por meio de um snapshot. Para evitar custos de snapshots em tabelas sem backup, trunque-as antes de tirar um snapshot.

# Criação de um snapshot manual
<a name="snapshot-create"></a>

Você pode criar um snapshot manual de um cluster a partir da lista de snapshots da forma a seguir. Ou então, você pode gerar um snapshot de um cluster no painel de configuração do cluster. Para obter mais informações, consulte [Snapshots e backups do Amazon Redshift](working-with-snapshots.md).

**nota**  
Tabelas sem backup não são aceitas em clusters provisionados com RA3 e grupos de trabalho do Amazon Redshift sem servidor. Uma tabela marcada como sem backup em um cluster do RA3 ou um grupo de trabalho sem servidor será tratada como uma tabela permanente da qual sempre será feito backup durante a criação de um snapshot e sempre restaurada quando ocorrer a restauração por meio de um snapshot. Para evitar custos de snapshots em tabelas sem backup, trunque-as antes de tirar um snapshot.

**Para criar um snapshot manual**

1. Faça login no Console de gerenciamento da AWS e abra o console do Amazon Redshift em [https://console.aws.amazon.com/redshiftv2/](https://console.aws.amazon.com/redshiftv2/).

1. No menu de navegação, escolha **Clusters**, **Snapshots** e a guia **Create snapshot** (Criar snapshot). A página de snapshot para criação de um snapshot manual é exibida. 

1. Insira as propriedades da definição do snapshot e escolha **Create snapshot (Criar snapshot)**. Pode levar algum tempo para o snapshot estar disponível. 

# Criar uma programação de snapshot
<a name="snapshot-schedule-create"></a>

O Amazon Redshift tira snapshots incrementais e automáticos de seus dados periodicamente e os salva no Amazon S3. Além disso, você pode capturar snapshots manuais de seus dados sempre que desejar. 

Todas as tarefas de snapshot no console do Amazon Redshift começam na lista de snapshots. Você pode filtrar a lista usando um intervalo de tempo, o tipo de snapshot e o cluster associado ao snapshot. Além disso, você pode classificar a lista por data, tamanho e tipo de snapshot. Dependendo do tipo de snapshot selecionado, você pode ter diferentes opções disponíveis para trabalhar com o snapshot. 

Para controlar com precisão quando snapshots são tirados, você pode criar uma programação de snapshot e anexá-la a um ou mais clusters. Você pode anexar uma programação quando criar um cluster ou modificando o cluster. Para obter mais informações, consulte [Programações de snapshots automatizados](working-with-snapshots.md#automated-snapshot-schedules).

**Para criar uma programação de snapshot**

1. Faça login no Console de gerenciamento da AWS e abra o console do Amazon Redshift em [https://console.aws.amazon.com/redshiftv2/](https://console.aws.amazon.com/redshiftv2/).

1. No menu de navegação, escolha **Clusters**, **Snapshots** e a guia **Snapshot schedules** (Programações de snapshots). As programações de snapshots são exibidas. 

1. Escolha **Add schedule (Adicionar programação)** para exibir a página para adicionar uma programação. 

1. Insira as propriedades da definição da programação e escolha **Add schedule (Adicionar programação)**. 

1. Na página exibida, você pode anexar clusters à sua nova programação de snapshots e escolher **OK**. 

# Compartilhar um snapshot
<a name="working-with-snapshot-share-snapshot"></a>

Você pode compartilhar um snapshot manual existente com outras contas de clientes da AWS, autorizando o acesso ao snapshot. Você pode autorizar até 20 para cada snapshot e 100 para cada chave do AWS Key Management Service (AWS KMS). Ou seja, se você tiver 10 snapshots criptografados com uma única chave KMS, poderá autorizar 10 contas da AWS para restaurar cada snapshot ou outras combinações que adicionem até 100 contas e não excedam 20 contas para cada snapshot. Uma pessoa conectada como usuário em uma das contas autorizadas pode então descrever o snapshot ou restaurá-lo para criar um novo cluster do Amazon Redshift em sua conta. Por exemplo, se você usar contas de cliente da AWS separadas para produção e teste, um usuário poderá fazer login usando a conta de produção e compartilhar um snapshot com usuários na conta de teste. Alguém conectado como um usuário da conta de teste poderá restaurar o snapshot a fim de criar um novo cluster de propriedade da conta de teste para fins de teste ou trabalho de diagnóstico. 

Um snapshot manual é propriedade permanente da conta de cliente da AWS em que foi criado. Somente usuários na conta proprietária do snapshot podem autorizar outras contas a acessar o snapshot ou revogar autorizações. Os usuários nas contas autorizadas somente podem descrever ou restaurar qualquer snapshot que tenha sido compartilhado com eles; eles não podem copiar nem excluir snapshots que tenham sido compartilhadas com eles. Uma autorização permanecerá em vigor até o proprietário do snapshot revogá-la. Se uma autorização for revogada, o usuário sido autorizado anteriormente perderá a visibilidade do snapshot e não poderá iniciar ações novas referenciando o snapshot. Se a conta estiver no processo de restauração do snapshot quando o acesso for revogado, a restauração será executada até ser concluída. Você não poderá excluir um snapshot enquanto ele tiver autorizações ativas; você deve revogar primeiramente todas as autorizações.

AWSAs contas de clientes da estão sempre autorizadas para acessar snapshots de propriedade da conta. As tentativas de autorizar ou revogar acesso para a conta do proprietário receberão um erro. Você não pode restaurar nem descrever um snapshot de propriedade de uma conta do cliente da AWS inativa. 

Depois que você tiver autorizado o acesso a uma conta do cliente da AWS, nenhum usuário nessa conta poderá realizar ações no snapshot, a menos que assuma um perfil com políticas que permitam isso.
+ Os usuários na conta do proprietário do snapshot podem autorizar e revogar o acesso a um snapshot apenas se assumirem um perfil com uma política do IAM que permita a execução dessas ações com uma especificação de recurso que inclua o snapshot. Por exemplo, a política a seguir permite que um usuário na conta da AWS `012345678912` autorize outras contas a acessarem um snapshot chamado `my-snapshot20130829`:

------
#### [ JSON ]

****  

  ```
  {
    "Version":"2012-10-17",		 	 	 
    "Statement":[
      {
        "Effect":"Allow",
        "Action":[
            "redshift:AuthorizeSnapshotAccess",
            "redshift:RevokeSnapshotAccess"
            ],
        "Resource":[
             "arn:aws:redshift:us-east-1:012345678912:snapshot:*/my-snapshot20130829"
            ]
      }
    ]
  }
  ```

------
+ Os usuários em uma conta da AWS com a qual um snapshot foi compartilhado não podem realizar ações nesse snapshot, a menos que tenham permissões referentes a essas ações. É possível fazer isso atribuindo a política a um perfil e assumindo o perfil. 
  + Para listar ou descrever um snapshot, eles devem ter uma políticas IAM que permita a ação `DescribeClusterSnapshots`. O seguinte código mostra um exemplo:

------
#### [ JSON ]

****  

    ```
    {
      "Version":"2012-10-17",		 	 	 
      "Statement":[
        {
          "Effect":"Allow",
          "Action":[
              "redshift:DescribeClusterSnapshots"
              ],
          "Resource":[
               "*"
              ]
        }
      ]
    }
    ```

------
  + Para restaurar um snapshot, um usuário deve assumir um perfil com uma política do IAM que permita a ação `RestoreFromClusterSnapshot` e tenha um elemento de recurso que abranja tanto o cluster que está tentando criar quanto o snapshot. Por exemplo, se um usuário na conta `012345678912` tiver um snapshot compartilhado `my-snapshot20130829` com a conta `219876543210`, para criar um cluster restaurando o snapshot, um usuário na conta `219876543210` deve assumir um perfil com uma política como a seguinte:

------
#### [ JSON ]

****  

    ```
    {
      "Version":"2012-10-17",		 	 	 
      "Statement":[
        {
          "Effect":"Allow",
          "Action":[
              "redshift:RestoreFromClusterSnapshot"
              ],
          "Resource":[
               "arn:aws:redshift:us-east-1:012345678912:snapshot:*/my-snapshot20130829",
               "arn:aws:redshift:us-east-1:219876543210:cluster:from-another-account"
              ]
        }
      ]
    }
    ```

------
  + Depois que o acesso a um snapshot tiver sido removido de uma conta da AWS, nenhum usuário nessa conta poderá acessar o snapshot. Isso ocorre mesmo que essas contas tenham políticas do IAM que permitam ações no recurso do snapshot compartilhado anteriormente.

## Compartilhar um snapshot de cluster usando o console
<a name="snapshot-share"></a>

No console, é possível autorizar outros usuários a acessar um snapshot manual que pertence a você e, mais tarde, revogar esse acesso quando ele não for mais necessário.

**Para compartilhar um snapshot com outra conta**

1. Faça login no Console de gerenciamento da AWS e abra o console do Amazon Redshift em [https://console.aws.amazon.com/redshiftv2/](https://console.aws.amazon.com/redshiftv2/).

1. No menu de navegação, escolha **Clusters**, **Snapshots** e o snapshot manual a ser compartilhado. 

1. Em **Actions (Ações)**, escolha **Manual snapshot settings (Configurações de snapshot manual)** para exibir as propriedades do snapshot manual. 

1. Insira a conta, ou contas, com a qual compartilhar na seção **Manage access (Gerenciar o acesso)** e escolha **Save (Salvar)**. 

## Considerações de segurança para compartilhamento de snapshots criptografados
<a name="snapshot-share-access-kms-key"></a>

 Quando você fornece acesso a um snapshot criptografado, o Redshift exige que a chave gerenciada pelo cliente do AWS KMS usada para criar o snapshot seja compartilhada com a conta ou as contas que estão realizando a restauração. Se a chave não for compartilhada, a tentativa de restaurar o snapshot resultará em um erro de acesso negado. A conta de recebimento não precisa de nenhuma permissão extra para restaurar um snapshot compartilhado. Quando você autoriza o acesso ao snapshot e compartilha a chave, a identidade que autoriza o acesso deve ter permissões `kms:DescribeKey` na chave usada para criptografar o snapshot. Essa permissão é descrita com mais detalhes em [Permissões do AWS KMS](https://docs.aws.amazon.com/kms/latest/developerguide/kms-api-permissions-reference.html). Para obter mais informações, consulte [DescribeKey](https://docs.aws.amazon.com/kms/latest/APIReference/API_DescribeKey.html) na documentação de referência de API do Amazon Redshift. 

A política de chave gerenciada pelo cliente pode ser atualizada programaticamente ou no console do AWS Key Management Service.

**nota**  
Se você usar uma chave do KMS padrão, não será necessário realizar nenhuma ação nem alterar nada no AWS KMS para compartilhar um snapshot.

### Permitir acesso à chave do AWS KMS para um snapshot criptografado
<a name="snapshot-share-access-kms-key-allowing-access"></a>

Para compartilhar a chave gerenciada pelo cliente do AWS KMS para um snapshot criptografado, atualize a política de chaves realizando as seguintes etapas:

1. Você pode fazer uma atualização com o nome do recurso da Amazon (ARN) da conta da AWS com a qual você está compartilhando como `Principal` na política de chaves do KMS.

1.  Permitir a ação `kms:Decrypt`. 

No exemplo de política de chaves a seguir, o usuário `111122223333` é o proprietário da chave do KMS, e o usuário `444455556666` é a conta com a qual a chave é compartilhada. Essa política de chaves concede à conta da AWS acesso ao exemplo de chave do KMS incluindo o ARN da identidade da conta-raiz da AWS para o usuário `444455556666` como `Principal` da política e permitindo a ação `kms:Decrypt`. 

------
#### [ JSON ]

****  

```
{
    "Id": "key-policy-1",
    "Version":"2012-10-17",		 	 	 
    "Statement": [
        {
            "Sid": "Allow use of the key",
            "Effect": "Allow",
            "Principal": {
                "AWS": [
                    "arn:aws:iam::111122223333:user/KeyUser",
                    "arn:aws:iam::444455556666:root"
                ]
            },
            "Action": [
                "kms:Decrypt"
            ],
            "Resource": "*"
        }
    ]
}
```

------

Depois que o acesso é concedido à chave do KMS gerenciada pelo cliente, a conta que restaura o snapshot criptografado deve criar um usuário ou função do AWS Identity and Access Management (IAM), se ainda não tiver. Além disso, essa conta da AWS também deve anexar uma política do IAM a esse usuário ou função do IAM que permita que eles restaurem um snapshot do banco de dados criptografado usando a chave do KMS. 

Para obter mais informações sobre como conceder acesso a uma chave do AWS KMS, consulte [Permitir que usuários de outras contas usem uma chave do KMS](https://docs.aws.amazon.com/kms/latest/developerguide/key-policy-modifying-external-accounts.html#cross-account-console), no Guia do desenvolvedor do AWS Key Management Service.

Para ter uma visão geral das principais políticas, consulte [Como o Amazon Redshift usa o AWS KMS](https://docs.aws.amazon.com/kms/latest/developerguide/services-redshift.html).

# Copiar um snapshot automatizado
<a name="snapshot-copy"></a>

Snapshots automatizados são excluídos automaticamente quando seus períodos de retenção expiram, quando você desabilita snapshots automatizados ou quando você exclui um cluster. Se você deseja armazenar um snapshot automatizado, pode copiá-lo para um snapshot manual. 

**Para copiar um snapshot automatizado**

1. Faça login no Console de gerenciamento da AWS e abra o console do Amazon Redshift em [https://console.aws.amazon.com/redshiftv2/](https://console.aws.amazon.com/redshiftv2/).

1. No menu de navegação, escolha **Clusters**, **Snapshots** e o snapshot a ser copiado. 

1. Em **Actions (Ações)**, escolha **Copy automated snapshot (Copiar snapshot automatizado)** para copiar o snapshot. 

1. Atualize as propriedades do novo snapshot e escolha **Copy (Copiar)**. 

# Copiar um snapshot em outra região da AWS
<a name="cross-region-snapshot-copy"></a>

Você pode configurar o Amazon Redshift para copiar automaticamente os snapshots (automatizado ou manual) de um cluster para outra região da AWS. Quando um snapshot é criado na região da AWS primária do cluster, ele é copiado para uma região da AWS secundária. As duas regiões da AWS são conhecidas respectivamente como *região da AWS de origem* e *região da AWS de destino*. Se você armazenar uma cópia de seus snapshots em outra região da AWS, poderá restaurar seu cluster a partir de dados recentes se algo afetar a região da AWS primária. Você pode configurar seu cluster para copiar snapshots para apenas uma região da AWS de destino por vez. Para conferir a lista de regiões do Amazon Redshift, consulte [Regiões e endpoints](https://docs.aws.amazon.com/general/latest/gr/rande.html) na *Referência geral da Amazon Web Services*.

Ao habilitar o Amazon Redshift para copiar automaticamente os snapshots para outra região da AWS, você especifica a região da AWS de destino para onde copiar os snapshots. Para snapshots automatizados, você também pode especificar o período de retenção para mantê-los na região da AWS de destino. Depois que um snapshot automatizado é copiado para a região da AWS de destino e atinge o período de retenção lá, ele é excluído da região da AWS de destino. Ao fazer isso, você mantém o uso do snapshot baixo. Para manter os snapshots automatizados por um período mais curto ou mais longo na região da AWS de destino, altere este período de retenção.

O período de retenção que você define para snapshots automatizados que são copiados para a região da AWS de destino é separado do período de retenção para snapshots automatizados na região da AWS de origem. O período de retenção padrão para snapshots copiados é sete dias. Esse período de sete dias somente se aplica a snapshots automatizados. Nas regiões da AWS de origem e destino, os snapshots manuais são excluídos no final do período de retenção do snapshot ou quando você os exclui manualmente.

Você pode desativar a cópia automática do snapshot de um cluster a qualquer momento. Quando você desativa esse recurso, os snapshots não são mais copiados da região da AWS de origem para a região da AWS de destino. Todos os snapshots automatizados copiados para a região da AWS de destino são excluídos à medida que atingem o limite do período de retenção, a menos que você crie cópias de snapshot manuais deles. Esses snapshots manuais e quaisquer snapshots manuais que foram copiados da região da AWS de destino são mantidos na região da AWS de destino até que você os exclua manualmente.

Para alterar a região da AWS de destino para a qual você copia os snapshots , primeiro desative o recurso de cópia automática. Em seguida, reative-o, especificando a nova região da AWS de destino.

Depois que um snapshot é copiado para a região da AWS de destino, ele se torna ativo e disponível para fins de restauração.

Para copiar snapshots de clusters criptografados pelo AWS KMS para outra região da AWS, crie uma concessão para o Amazon Redshift para usar uma chave gerenciada pelo cliente na região da AWS de destino. Em seguida, escolha essa concessão ao habilitar a cópia de snapshots na região da AWS de origem. Para obter mais informações sobre como configurar concessões de cópia do snapshot, consulte [Copiar snapshots criptografados pelo AWS KMS para outra Região da AWS](working-with-db-encryption.md#configure-snapshot-copy-grant).

# Restauração de um cluster usando um snapshot
<a name="working-with-snapshot-restore-cluster-from-snapshot"></a>

Um snapshot contém dados de todos os bancos de dados em execução no cluster. Ele também contém informações sobre seu cluster, inclusive o número de nós, tipo de nós e o nome de usuário administrador. Se você restaurar seu cluster a partir de um snapshot, o Amazon Redshift usa as informações do cluster para criar um novo cluster. Em seguida, ele restaura todos os bancos de dados dos dados do snapshot.

**nota**  
Tabelas sem backup não são aceitas em clusters provisionados com RA3 e grupos de trabalho do Amazon Redshift sem servidor. Uma tabela marcada como sem backup em um cluster do RA3 ou um grupo de trabalho sem servidor será tratada como uma tabela permanente da qual sempre será feito backup durante a criação de um snapshot e sempre restaurada quando ocorrer a restauração por meio de um snapshot.

Para o novo cluster criado a partir do snapshot original, você pode escolher a configuração, como o tipo e o número de nós. O cluster é restaurado na mesma região da AWS e em uma zona de disponibilidade aleatória escolhida pelo sistema, a menos que você especifique outra zona de disponibilidade em sua solicitação. Ao restaurar um cluster a partir de um snapshot, você poderá escolher um acompanhamento de manutenção compatível para o novo cluster.

**nota**  
Quando você restaura um snapshot para um cluster com outra configuração, o snapshot deve ser obtido em um cluster com a versão 1.0.10013 ou posterior. 

Quando uma restauração está em andamento, os eventos geralmente são emitidos na seguinte ordem:

1. RESTORE\$1STARTED — REDSHIFT-EVENT-2008 enviado quando o processo de restauração começa. 

1. RESTORE\$1SUCCEEDED — REDSHIFT-EVENT-3003 enviado quando o novo cluster foi criado. 

   O cluster está disponível para consultas. 

1. DATA\$1TRANSFER\$1COMPLETED — REDSHIFT-EVENT-3537 enviado quando a transferência de dados é concluída 

**nota**  
Os clusters RA3 emitem apenas os eventos RESTORE\$1STARTED e RESTORE\$1SUCCEEDED. Não há transferência de dados explícita a ser feita depois que um RESTORE for bem-sucedido porque os tipos de nó RA3 armazenam dados no armazenamento gerenciado do Amazon Redshift. Com os nós RA3, os dados são continuamente transferidos entre os nós RA3 e o armazenamento gerenciado do Amazon Redshift como parte do processamento normal de consultas. Os nós RA3 armazenam dados quentes localmente e mantêm blocos consultados com menos frequência no armazenamento gerenciado do Amazon Redshift automaticamente. 

Você pode monitorar o andamento de uma restauração chamando a operação de API [DescribeClusters](https://docs.aws.amazon.com/redshift/latest/APIReference/API_DescribeClusters.html) ou exibindo os detalhes do cluster no Console de gerenciamento da AWS. Para uma restauração em andamento, eles exibem informações como o tamanho dos dados do snapshot, a taxa de transferência, o tempo decorrido e o tempo estimado restante. Para obter uma descrição dessas métricas, acesse [RestoreStatus](https://docs.aws.amazon.com/redshift/latest/APIReference/API_RestoreStatus.html).

Você não pode usar um snapshot para restaurar o estado anterior de um cluster ativo.

**nota**  
Quando você restaurar um snapshot em um novo cluster, o security group e o parameter group padrão serão usados, a menos que você especifique valores diferentes. 

Talvez você queira restaurar um snapshot para um cluster com uma configuração diferente por estas razões:
+ Quando um cluster é composto por tipos de nós menores e você deseja consolidá-lo em um tipo maior com menos nós. 
+ Quando você monitorou seu workload e determinou a necessidade de migrar para um tipo de nó com mais CPU e armazenamento. 
+ Quando você deseja medir a performance de workloads de teste com tipos de nós diferentes. 

A restauração tem as seguintes restrições: 
+ A nova configuração de nó deve ter armazenamento suficiente para os dados existentes. Mesmo quando você adiciona nós, sua nova configuração pode não ter armazenamento suficiente por causa da maneira como os dados são redistribuídos. 
+ A operação de restauração verifica se o snapshot foi criado em uma versão de cluster compatível com a versão de cluster do novo cluster. Se o novo cluster tiver um nível de versão muito cedo, a operação de restauração falhará e reporta mais informações em uma mensagem de erro.
+ As configurações possíveis (número de nós e tipo de nó) que você pode restaurar são determinadas pelo número de nós no cluster original e pelo tipo de nó de destino do novo cluster. Para determinar as possíveis configurações disponíveis, você pode usar o console do Amazon Redshift ou o comando da AWS CLI `describe-node-configuration-options` com `action-type restore-cluster`. Para obter mais informações sobre a restauração usando o console do Amazon Redshift, consulte [Restauração de um cluster usando um snapshot](#working-with-snapshot-restore-cluster-from-snapshot). 

As etapas a seguir consideram um cluster com muitos nós e o consolida em um tipo de nó maior com um número menor de nós usando a AWS CLI. Para este exemplo, começamos com um cluster de origem de 24 nós . Nesse caso, suponha que já tenhamos criado um snapshot desse cluster e deseje restaurá-lo para um tipo de nó maior.

1.  Execute o seguinte comando para obter os detalhes de um cluster de 24 nós. 

   ```
   aws redshift describe-clusters --region eu-west-1 --cluster-identifier mycluster-123456789012
   ```

1. Execute o seguinte comando para obter os detalhes do snapshot. 

   ```
   aws redshift describe-cluster-snapshots --region eu-west-1 --snapshot-identifier mycluster-snapshot
   ```

1. Execute o seguinte comando para descrever as opções disponíveis para esse snapshot. 

   ```
   aws redshift describe-node-configuration-options --snapshot-identifier mycluster-snapshot --region eu-west-1 --action-type restore-cluster
   ```

   Este comando retorna uma lista de opções com os tipos de nós, o número de nós e a utilização do disco recomendados para cada opção. Para este exemplo, o comando anterior lista as seguintes configurações de nós possíveis. Optamos por fazer a restauração para um cluster de três nós.

   ```
   {
       "NodeConfigurationOptionList": [
           {
               "EstimatedDiskUtilizationPercent": 65.26134808858235,
               "NodeType": "dc2.large",
               "NumberOfNodes": 24
           },
           {
               "EstimatedDiskUtilizationPercent": 32.630674044291176,
               "NodeType": "dc2.large",
               "NumberOfNodes": 48
           },
           {
               "EstimatedDiskUtilizationPercent": 65.26134808858235,
               "NodeType": "dc2.8xlarge",
               "NumberOfNodes": 3
           },
           {
               "EstimatedDiskUtilizationPercent": 48.94601106643677,
               "NodeType": "dc2.8xlarge",
               "NumberOfNodes": 4
           },
           {
               "EstimatedDiskUtilizationPercent": 39.156808853149414,
               "NodeType": "dc2.8xlarge",
               "NumberOfNodes": 5
           },
           {
               "EstimatedDiskUtilizationPercent": 32.630674044291176,
               "NodeType": "dc2.8xlarge",
               "NumberOfNodes": 6
           }
       ]
   }
   ```

1. Execute o comando a seguir para restaurar o snapshot para a configuração do cluster que escolhemos. Após a restauração desse cluster, temos o mesmo conteúdo que o cluster de origem, mas os dados foram consolidados em três nós `dc2.8xlarge`. 

   ```
   aws redshift restore-from-cluster-snapshot --region eu-west-1 --snapshot-identifier mycluster-snapshot --cluster-identifier mycluster-123456789012-x --node-type dc2.8xlarge --number-of-nodes 3
   ```

Se você tiver nós reservados (por exemplo, nós reservados DC2), poderá atualizar para nós reservados RA3. Faça isso para restaurar a partir de um snapshot ou para executar um redimensionamento elástico. Você pode usar o console se orientar nesse processo. Para obter mais informações sobre a atualização para nós RA3, consulte [Atualizar para os tipos de nó RA3](https://docs.aws.amazon.com/redshift/latest/mgmt/working-with-clusters.html#rs-upgrading-to-ra3). 

**Como restaurar um cluster por meio de um snapshot no console**

1. Faça login no Console de gerenciamento da AWS e abra o console do Amazon Redshift em [https://console.aws.amazon.com/redshiftv2/](https://console.aws.amazon.com/redshiftv2/).

1. No menu de navegação, escolha **Clusters**, **Snapshots** e o snapshot a ser restaurado. 

1. Escolha **Restore from snapshot (Restaurar de snapshot)** para visualizar a **Cluster configuration (Configuração do cluster)** e os valores de **Cluster details (Detalhes do cluster)** do novo cluster a ser criado usando as informações do snapshot. 

1. Atualize as propriedades do novo cluster e escolha **Restore cluster from snapshot (Restaurar cluster de snapshot)**. 

Após a restauração do snapshot do cluster, o data warehouse restaurado é criptografado com a mesma chave do AWS KMS personalizada que estava sendo usada no momento em que o snapshot foi criado. Se o snapshot não tiver uma chave do KMS personalizada, a lógica de criptografia de backup do Amazon Redshift dependerá dos seguintes fatores:
+ O tipo de data warehouse do Amazon Redshift para o qual você está restaurando o snapshot.
+ O tipo de criptografia do cluster no momento em que o snapshot foi criado.

Para saber como seu data warehouse será criptografado depois de restaurá-lo por meio do snapshot do cluster, consulte a seguinte tabela:


| Tipos de destino | Tipo de criptografia do snapshot | Tipo de criptografia de destino | 
| --- | --- | --- | 
|  Cluster provisionado  |  Criptografado com uma Chave gerenciada pela AWS  |  Criptografado com uma Chave gerenciada pela AWS  | 
|  Cluster provisionado  |  Criptografado com uma Chave pertencente à AWS  |  Criptografado com uma Chave pertencente à AWS  | 
|  Namespace sem servidor  |  Criptografado com uma Chave gerenciada pela AWS  |  Criptografado com uma Chave pertencente à AWS  | 
|  Namespace sem servidor  |  Criptografado com uma Chave pertencente à AWS  |  Criptografado com uma Chave pertencente à AWS  | 

Se o AWS Secrets Manager gerenciou a senha de administrador do cluster no momento em que o snapshot foi feito, você deve continuar usando o AWS Secrets Manager para gerenciar a senha de administrador. Você poderá se recusar a usar um segredo depois de restaurar o cluster atualizando as credenciais de administrador do cluster na página de detalhes do cluster.

Se você tiver nós reservados, poderá atualizar para nós reservados RA3. Faça isso para restaurar a partir de um snapshot ou para executar um redimensionamento elástico. Você pode usar o console se orientar nesse processo. Para obter mais informações sobre a atualização para nós RA3, consulte [Atualizar para os tipos de nó RA3](https://docs.aws.amazon.com/redshift/latest/mgmt/working-with-clusters.html#rs-upgrading-to-ra3). 

# Restaurar uma tabela de um snapshot
<a name="working-with-snapshot-restore-table-from-snapshot"></a>

Você pode restaurar uma única tabela de um snapshot, em vez de restaurar um cluster inteiro. Ao restaurar uma única tabela de um snapshot, você especifica o snapshot, o banco de dados, o esquema e o nome da tabela de origem, além do banco de dados e esquema de origem e do nome de uma nova tabela para a tabela restaurada.

**nota**  
Tabelas sem backup não são aceitas em clusters provisionados com RA3 e grupos de trabalho do Amazon Redshift sem servidor. Uma tabela marcada como sem backup em um cluster do RA3 ou um grupo de trabalho sem servidor será tratada como uma tabela permanente da qual sempre será feito backup durante a criação de um snapshot e sempre restaurada quando ocorrer a restauração por meio de um snapshot. No entanto, a restauração seletiva de tabelas sem backup não é aceita.

O nome da nova tabela não pode ser o nome de uma tabela existente. Para substituir uma tabela existente por uma tabela restaurada de um snapshot, renomeie ou ignore a tabela existente antes de restaurar a tabela do snapshot.

A tabela de destino é criada usando-se as definições de coluna da tabela de origem, os atributos da tabela e os atributos da coluna, exceto as chaves externas. Para evitar conflitos por causa de dependências, a tabela de destino não herda chaves externas da tabela de origem. Todas as dependências, como visualizações ou permissões concedidas na tabela de origem, não são aplicadas à tabela de destino. 

Se o proprietário da tabela de origem existir, esse usuário de banco de dados será o proprietário da tabela restaurada, desde que o usuário tenha permissões suficientes para se tornar o proprietário de uma relação no banco de dados e no esquema especificados. Do contrário, a tabela restaurada será de propriedade do usuário administrador que foi criado quando o cluster foi iniciado.

A tabela restaurada retorna ao estado em que estava no momento em que o backup foi feito. Isso inclui regras de visibilidade de transação definidas pela adesão do Amazon Redshift ao [isolamento serializável](https://docs.aws.amazon.com/redshift/latest/dg/c_serial_isolation.html), o que significa que os dados serão imediatamente visíveis para transações em andamento iniciadas após o backup.

Restaurar uma tabela de um snapshot tem as seguintes limitações:
+ Você pode restaurar uma tabela somente no cluster atual, em execução ativa, e de um snapshot feito desse cluster.
+ Você pode restaurar somente uma tabela por vez.
+ Você não pode restaurar uma tabela de um snapshot de cluster feito antes de um cluster ser redimensionado. Uma exceção é que você pode restaurar uma tabela após um redimensionamento elástico se o tipo de nó não for alterado. 
+ Todas as dependências, como visualizações ou permissões concedidas na tabela de origem, não são aplicadas à tabela de destino.
+ Se a segurança no nível da linha estiver ativada para uma tabela que está sendo restaurada, o Amazon Redshift restaurará a tabela com a segurança no nível da linha ativada. 

**Para restaurar uma tabela de um snapshot**

1. Faça login no Console de gerenciamento da AWS e abra o console do Amazon Redshift em [https://console.aws.amazon.com/redshiftv2/](https://console.aws.amazon.com/redshiftv2/).

1. No menu de navegação, escolha **Clusters** e o cluster que você deseja usar para restaurar uma tabela. 

1. Em **Actions (Ações)**, escolha **Restore table (Restaurar tabela)** para exibir a página **Restore table (Restaurar tabela)**. 

1. Insira informações sobre qual snapshot, tabela de origem e tabela de destino usar e escolha **Restore table (Restaurar tabela)**. 

**Example Exemplo: restaurar uma tabela de um snapshot usando a AWS CLI**  
O exemplo a seguir usa o comando `restore-table-from-cluster-snapshot` da AWS CLI para restaurar a tabela `my-source-table` do esquema `sample-database` no `my-snapshot-id`. Você pode usar o comando `describe-table-restore-status` da AWS CLI para revisar o status da operação de restauração. O exemplo restaura o snapshot para o cluster `mycluster-example` com o nome de uma nova tabela `my-new-table`.  

```
aws redshift restore-table-from-cluster-snapshot --cluster-identifier mycluster-example 
                                                 --new-table-name my-new-table 
                                                 --snapshot-identifier my-snapshot-id 
                                                 --source-database-name sample-database 
                                                 --source-table-name my-source-table
```

# Restaurar um namespace com tecnologia sem servidor usando um snapshot
<a name="snapshot-restore-provisioned-to-serverless"></a>

 A restauração de um namespace com tecnologia sem servidor de um snapshot substitui todos os bancos de dados do namespace por bancos de dados no snapshot. Para obter mais informações sobre snapshots sem servidor, consulte [Trabalhar com snapshots e pontos de recuperação](https://docs.aws.amazon.com/redshift/latest/mgmt/serverless-snapshots-recovery-points.html). O Amazon Redshift converte automaticamente tabelas com chaves intercaladas em chaves compostas quando você restaura um snapshot de cluster provisionado para um namespace do Amazon Redshift sem servidor. Para obter mais informações sobre chaves de classificação, consulte [Trabalhar com chaves de classificação](https://docs.aws.amazon.com/redshift/latest/dg/t_Sorting_data.html). 

Para restaurar um snapshot de cluster provisionado para um namespace de tecnologia sem servidor:

1. Faça login no Console de gerenciamento da AWS e abra o console do Amazon Redshift em [https://console.aws.amazon.com/redshiftv2/](https://console.aws.amazon.com/redshiftv2/).

1. No menu de navegação, escolha **Clusters**, **Snapshots** e escolha o snapshot a ser copiado.

1. Selecione **Restore from snapshot** (Restaurar a partir do snapshot), **Restore to serverless endpoint** (Restaurar para endpoint com tecnologia sem servidor).

1. Escolha o namespace para o qual você deseja fazer a restauração.

1. Confirme que você deseja restaurar a partir do snapshot. Escolha **restore** (restaurar). Essa ação substitui todos os bancos de dados no namespace de tecnologia sem servidor pelos dados do cluster provisionado.

# Configuração de cópia de snapshots entre regiões para um cluster não criptografado
<a name="snapshot-crossregioncopy-configure"></a>

Você pode configurar o Amazon Redshift para copiar snapshots de um cluster para outra região da AWS. Para configurar a cópia de snapshot entre regiões, você precisa habilitar este recurso de cópia para cada cluster e configurar onde copiar os snapshots e por quanto tempo manter os snapshots automatizados ou manuais copiados na região da AWS de destino. Quando a cópia entre regiões é habilitada para um cluster, todos os novos snapshots manuais e automatizados são copiados para a região da AWS especificada. Os nomes dos snapshots copiados são prefixados com **copy:**.

**Como configurar um snapshot entre regiões**

1. Faça login no Console de gerenciamento da AWS e abra o console do Amazon Redshift em [https://console.aws.amazon.com/redshiftv2/](https://console.aws.amazon.com/redshiftv2/).

1. No menu de navegação, escolha **Clusters**, depois selecione o cluster para o qual você deseja mover snapshots.

1. Em **Ações**, escolha **Configurar snapshots entre regiões**.

   A caixa de diálogo “Configurar entre regiões” é exibida.

1. Em **Copiar snapshots**, escolha **Sim**.

1. Em **Região da AWS de destino**, escolha a região da AWS para a qual deseja copiar os snapshots.

1. Em **Período de retenção de snapshot automatizado (dias)**, escolha o número de dias durante os quais deseja que os snapshots automatizados sejam retidos na região da AWS de destino antes de serem excluídos.

1. Em **Período de retenção de snapshot manual**, escolha o valor que representa o número de dias durante os quais você deseja que os snapshots manuais sejam retidos na região da AWS de destino antes de serem excluídos. Se escolher **Valor personalizado**, o período de retenção deve ser entre 1 e 3653 dias.

1. Escolha **Salvar**.

# Configurar a cópia de snapshots entre regiões para um cluster criptografado pelo AWS KMS
<a name="xregioncopy-kms-encrypted-snapshot"></a>

 Ao iniciar um cluster do Amazon Redshift, é possível configurar uma concessão de cópia de snapshot para uma chave raiz em sua conta na Região da AWS de destino. Se você não configurar uma concessão, os snapshots na região de destino serão criptografados com uma chave padrão de propriedade da AWS. Ao fazer isso, você permite que o Amazon Redshift execute operações de criptografia na região da AWS de destino.

O procedimento a seguir descreve o processo de habilitação de cópia de snapshot entre regiões para um cluster criptografado pelo AWS KMS. Para obter mais informações sobre criptografia no Amazon Redshift e concessões de cópia de snapshot, consulte [Copiar snapshots criptografados pelo AWS KMS para outra Região da AWS](working-with-db-encryption.md#configure-snapshot-copy-grant). 

**Para configurar um snapshot entre regiões para um cluster criptografado pelo AWS KMS**

1. Faça login no Console de gerenciamento da AWS e abra o console do Amazon Redshift em [https://console.aws.amazon.com/redshiftv2/](https://console.aws.amazon.com/redshiftv2/).

1. No menu de navegação, escolha **Clusters**, depois selecione o cluster para o qual você deseja mover snapshots.

1. Em **Ações**, escolha **Configurar snapshots entre regiões**.

   A caixa de diálogo “Configurar entre regiões” é exibida.

1. Em **Copiar snapshots**, escolha **Sim**.

1. Em **Região da AWS de destino**, escolha a região da AWS para a qual deseja copiar os snapshots.

1. Em **Período de retenção de snapshot automatizado (dias)**, escolha o número de dias durante os quais deseja que os snapshots automatizados sejam retidos na região da AWS de destino antes de serem excluídos.

1. Em **Período de retenção de snapshot manual**, escolha o valor que representa o número de dias durante os quais você deseja que os snapshots manuais sejam retidos na região da AWS de destino antes de serem excluídos. Se escolher **Valor personalizado**, o período de retenção deve ser entre 1 e 3653 dias.

1. Escolha **Salvar**.

# Modificar o período de retenção de snapshots manuais
<a name="snapshot-manual-retention-period"></a>

É possível alterar o período de retenção do snapshot manual modificando as configurações do snapshot.

**Para alterar o período de retenção do snapshot manual**

1. Faça login no Console de gerenciamento da AWS e abra o console do Amazon Redshift em [https://console.aws.amazon.com/redshiftv2/](https://console.aws.amazon.com/redshiftv2/).

1. No menu de navegação, escolha **Clusters**, **Snapshots** e o snapshot manual a ser alterado. 

1. Em **Actions (Ações)**, escolha **Manual snapshot settings (Configurações de snapshot manual)** para exibir as propriedades do snapshot manual. 

1. Insira as propriedades revisadas da definição do snapshot e escolha **Save (Salvar)**. 

# Alteração do período de retenção para a cópia de snapshots entre regiões
<a name="snapshot-crossregioncopy-modify"></a>

Após configurar uma cópia de snapshot entre regiões, talvez você queira alterar as configurações. Você pode, facilmente, alterar o período de retenção selecionando um novo número de dias e salvando as alterações. 

**Atenção**  
Não é possível modificar a região da AWS de destino após a configuração da cópia do snapshot entre regiões.   
Se você deseja copiar snapshots para uma região da AWS diferente, primeiro desative a cópia de snapshot entre regiões. Em seguida, reative-o com uma nova região de destino da AWS e período de retenção. Todos os snapshots automatizados são excluídos depois que você desabilita a cópia de snapshots entre regiões. Portanto, você deve determinar se há algum que você queira manter e copiá-los para snapshots manuais antes de desabilitar a cópia de snapshots entre regiões.

**Como modificar um snapshot entre regiões**

1. Faça login no Console de gerenciamento da AWS e abra o console do Amazon Redshift em [https://console.aws.amazon.com/redshiftv2/](https://console.aws.amazon.com/redshiftv2/).

1. No menu de navegação, escolha **Clusters** e o cluster para o qual você deseja modificar snapshots.

1. Em **Actions (Ações)**, escolha **Configure cross-region snapshot (Configurar snapshot entre regiões)** para exibir as propriedades do snapshot. 

1. Insira as propriedades revisadas da definição do snapshot e escolha **Save (Salvar)**. 

# Excluir um snapshot manual
<a name="snapshot-delete"></a>

Você pode excluir os snapshots manuais selecionando um ou mais snapshots na lista de snapshots.

**Para excluir um snapshot manual**

1. Faça login no Console de gerenciamento da AWS e abra o console do Amazon Redshift em [https://console.aws.amazon.com/redshiftv2/](https://console.aws.amazon.com/redshiftv2/).

1. No menu de navegação, escolha **Clusters**, **Snapshots** e o snapshot a ser excluído. 

1. Em **Actions (Ações)**, escolha **Delete snapshot (Excluir snapshot)** para excluir o snapshot. 

1. Confirme a exclusão dos snapshots listados e escolha **Delete (Excluir)**. 

# Registrar um cluster no AWS Glue Data Catalog
<a name="register-cluster"></a>

Você pode registrar clusters inteiros no AWS Glue Data Catalog e criar catálogos gerenciados pelo AWS Glue. É possível acessar esses catálogos com qualquer mecanismo SQL que seja compatível com a API REST do Apache Iceberg. Para obter mais informações sobre como criar catálogos compatíveis com o Apache Iceberg usando o Amazon Redshift, consulte [Apache Iceberg compatibility for Amazon Redshift](https://docs.aws.amazon.com/redshift/latest/dg/iceberg-integration_overview.html) no Guia do desenvolvedor de banco de dados do Amazon Redshift.

**Como registrar um cluster no AWS Glue Data Catalog**

1. Faça login no Console de gerenciamento da AWS e abra o console do Amazon Redshift em [https://console.aws.amazon.com/redshiftv2/](https://console.aws.amazon.com/redshiftv2/).

1. No menu de navegação, escolha **Clusters**. Os clusters de sua conta na Região da AWS atual são listados. Um subconjunto de propriedades de cada cluster é exibido nas colunas na lista. Se você não tiver nenhum cluster, escolha **Create cluster (Criar cluster)** para criar um.

1. Escolha o nome do cluster que você deseja registrar.

1.  Em **Ações**, escolha **Registrar no AWS Glue Data Catalog**. A caixa pop-up **Registrar no AWS Glue Data Catalog** aparece. 

1. Em **ID da conta de destino**, insira o ID da conta da AWS na qual você deseja registrar o cluster. Esse é o ID da conta que conterá o catálogo no AWS Glue Data Catalog.

1.  Insira um nome em **Registrar namespace como**. Esse será o nome do cluster no Catálogo de Dados. 

1.  Escolha **Registrar**. O console do AWS Lake Formation será aberto. 

1.  Siga o processo de criação do catálogo no AWS Lake Formation. Para obter informações sobre como criar um catálogo, consulte [Bringing Amazon Redshift data into the AWS Glue Data Catalog](https://docs.aws.amazon.com/lake-formation/latest/dg/managing-namespaces-datacatalog.html) no Guia do desenvolvedor do AWS Lake Formation.