Integrações ETL zero do Aurora com o Amazon Redshift

Ajudam você a obter insights holísticos de várias fontes de dados.

Eliminam a necessidade de criar e manter canais de dados complexos que executam operações de extração, transformação e carregamento (ETL). As integrações ETL zero eliminam os desafios que surgem com a criação e o gerenciamento de pipelines, provisionando-os e gerenciando-os para você.

Reduzem a carga e os custos operacionais para que você possa se concentrar em melhorar as aplicações.

Permitem que você aproveite os recursos de análise e ML do Amazon Redshift para obter insights de dados transacionais e outros dados, a fim de responder de forma eficaz a eventos críticos e urgentes.

O cluster de banco de dados de origem deve estar na mesma região do data warehouse do Amazon Redshift de destino.

Não será possível renomear um cluster de banco de dados ou qualquer uma de suas instâncias se o cluster tiver integrações existentes.

Não é possível criar várias integrações entre os mesmos bancos de dados de origem e destino.

Você não pode excluir um cluster de banco de dados que tenha integrações existentes. É necessário excluir todas as integrações correspondentes primeiro.

Se você interromper o cluster de banco de dados de origem, as últimas transações provavelmente não serão replicadas no data warehouse de destino enquanto você não retomar o cluster.

Se o cluster for a origem de uma implantação azul/verde, os ambientes azul e verde não poderão ter integrações ETL zero existentes durante a transição. Você deve excluir a integração primeiro, alternar e, depois, recriá-la.

Um cluster de banco de dados deve conter pelo menos uma instância de banco de dados para ser a origem de uma integração.

Você não pode criar uma integração para um cluster de banco de dados de origem que seja um clone entre contas, como aqueles compartilhados usando AWS Resource Access Manager (AWS RAM).

Se o cluster de origem for o cluster de banco de dados primário em um banco de dados global do Aurora e fizer o failover em um de seus clusters secundários, a integração se tornará inativa. Você precisa excluir e recriar a integração.

Não é possível criar uma integração para um banco de dados de origem que tenha outra integração sendo criada ativamente.

Quando você cria inicialmente uma integração ou quando uma tabela está sendo ressincronizada, a propagação de dados da origem para o destino pode levar de 20 a 25 minutos ou mais, dependendo do tamanho do banco de dados de origem. Esse atraso pode levar a um maior atraso na réplica.

Alguns tipos de dados não compatíveis. Para ter mais informações, consulte Diferenças de tipos de dados entre os bancos de dados Aurora e Amazon Redshift.

As tabelas do sistema, tabelas temporárias e visualizações não são replicadas no Amazon Redshift.

Operações de partição ALTER TABLE fazem com que a tabela seja ressincronizada para recarregar dados do Aurora no Amazon Redshift. A tabela não estará disponível para consulta durante a ressincronização. Para ter mais informações, consulte Uma ou mais das minhas tabelas do Amazon Redshift exigem ressincronização..

Seu cluster de banco de dados de origem deve estar executando uma versão compatível do Aurora MySQL. Para conferir uma lista de versões compatíveis, consulte Regiões e mecanismos de banco de dados do Aurora compatíveis com integrações ETL zero com o Amazon Redshift.

As integrações ETL zero dependem do registro em log binário (binlog) do MySQL para capturar alterações contínuas de dados. Não use a filtragem de dados baseada em log binário, pois isso pode causar inconsistências de dados entre os bancos de dados de origem e de destino.

As integrações ETL zero são compatíveis apenas com bancos de dados configurados para usar o mecanismo de armazenamento InnoDB.

Referências de chave externa com atualizações de tabelas predefinidas não são compatíveis. Especificamente, as regras ON DELETE e ON UPDATE não são compatíveis com as ações CASCADE, SET NULL e SET DEFAULT. A tentativa de criar ou atualizar uma tabela com essas referências a outra tabela colocará a tabela em um estado de falha.

As transações XA realizadas no cluster de banco de dados de origem fazem com que a integração entre no estado Syncing.

O cluster de banco de dados de origem executar uma versão compatível do Aurora PostgreSQL. Para conferir uma lista de versões compatíveis, consulte Regiões e mecanismos de banco de dados do Aurora compatíveis com integrações ETL zero com o Amazon Redshift.

Se você selecionar um cluster de banco de dados de origem do Aurora PostgreSQL, deverá especificar pelo menos um padrão de filtro de dados. No mínimo, o padrão deve incluir um único banco de dados (database-name.*.*) para replicação no Amazon Redshift. Para ter mais informações, consulte Filtragem de dados para integrações ETL zero do Aurora com o Amazon Redshift..

Todos os bancos de dados criados no cluster de banco de dados do Aurora PostgreSQL de origem devem usar a codificação UTF-8.

Se você realizar transações de particionamento declarativo no cluster de banco de dados de origem, todas as tabelas afetadas entrarão em um estado de falha e não estarão mais acessíveis no Amazon Redshift.

Transações em duas fases não são aceitas.

Se você excluir todas as instâncias de banco de dados de um cluster de banco de dados que seja a origem de uma integração, depois adicionar novamente uma instância de banco de dados, a replicação será interrompida entre os clusters de origem e de destino.

O cluster de banco de dados de origem não pode usar o Aurora Limitless Database.