Limitações da utilização do PostgreSQL como destino Requisitos de segurança para o PostgreSQL como destino Configurações de endpoint Tipos de dados de destino do PostgreSQL Utilizar o Babelfish para Aurora PostgreSQL como destino

Utilizar um banco de dados PostgreSQL como destino do AWS Database Migration Service

Você pode migrar dados para bancos de dados PostgreSQL AWS DMS usando, seja de outro banco de dados PostgreSQL ou de um dos outros bancos de dados compatíveis.

Para obter informações sobre as versões do PostgreSQL AWS DMS que oferecem suporte como destino, consulte. Metas para AWS DMS

nota

O Amazon Aurora Serverless está disponível como destino para o Amazon Aurora com compatibilidade com o PostgreSQL. Para obter mais informações sobre o Amazon Aurora Serverless, consulte Usando o Amazon Aurora Serverless v2 no Guia do usuário do Amazon Aurora.
Os clusters de banco de dados do Aurora Sem Servidor são acessíveis apenas de uma Amazon VPC e não podem utilizar um Endereço IP público. Portanto, se você tiver uma instância de replicação em uma região diferente da do Aurora PostgreSQL Sem Servidor, configure o Emparelhamento da VPC. Caso contrário, verifique a disponibilidade das regiões do Aurora PostgreSQL Sem Servidor e decida utilizar uma dessas regiões para o Aurora PostgreSQL Sem Servidor e a instância de replicação.
O recurso Babelfish está incorporado ao Amazon Aurora sem custo adicional. Para obter mais informações, consulte Utilizar o Babelfish para Aurora PostgreSQL como destino do AWS Database Migration Service.

AWS DMS adota uma table-by-table abordagem ao migrar dados da origem para o destino na fase de carga total. Não é possível garantir a ordem da tabela durante a fase de Carregamento total. As tabelas ficam dessincronizadas durante a fase de Carregamento total e enquanto transações em cache de tabelas individuais estão sendo aplicadas. Como resultado, restrições de integridade referencial ativa podem gerar falhas de tarefas durante a fase de Carregamento total.

No PostgreSQL, chaves externas (restrições de integridade referencial) são implementadas usando triggers. Durante a fase de carga total, AWS DMS carrega cada tabela uma de cada vez. Recomendamos que você desative as restrições de chave externa durante um carregamento total, usando um dos seguintes métodos:

Desative temporariamente todos os triggers da instância e conclua o carregamento total.
Use o parâmetro session_replication_role no PostgreSQL.

Em determinado momento, um trigger pode estar em um dos seguintes estados: origin, replica, always, ou disabled. Quando o parâmetro session_replication_role é definido como replica, apenas triggers no estado replica ficam ativos, e eles são disparados quando chamados. Caso contrário, os triggers permanecem inativos.

PostgreSQL tem um mecanismo à prova de falhas para impedir que uma tabela seja truncada, mesmo quando session_replication_role é definido. É possível utilizar isso como alternativa para desativar os acionadores, para ajudar a executar a carga máxima até a conclusão. Para isso, defina o modo de preparação da tabela de destino DO_NOTHING. Caso contrário, as operações DROP e TRUNCATE falharão quando houver restrições de chave externa.

No Amazon RDS, é possível controlar esse parâmetro utilizando um grupo de parâmetros. Para uma instância do PostgreSQL em execução no Amazon EC2, é possível definir o parâmetro diretamente.

Para obter detalhes adicionais sobre como trabalhar com um banco de dados PostgreSQL como destino, consulte as AWS DMS seções a seguir:

Tópicos

Limitações no uso do PostgreSQL como alvo para AWS Database Migration Service
Requisitos de segurança ao usar um banco de dados PostgreSQL como alvo para AWS Database Migration Service
Configurações de endpoint e atributos extras de conexão (ECAs) ao usar o PostgreSQL como destino para AWS DMS
Tipos de dados de destino do PostgreSQL
Usando o Babelfish para Aurora PostgreSQL como alvo para AWS Database Migration Service

Limitações no uso do PostgreSQL como alvo para AWS Database Migration Service

As seguintes limitações aplicam-se à utilização de um banco de dados PostgreSQL como destino para o AWS DMS:

Para migrações heterogêneas, o tipo de dados JSON é convertido internamente no tipo de dados CLOB nativo.
Em uma migração do Oracle para o PostgreSQL, se uma coluna no Oracle contiver um caractere NULL (valor hexadecimal U+0000), converterá o caractere NULL em um espaço (valor hexadecimal U+0020) AWS DMS . Isso deve-se a uma limitação do PostgreSQL.
AWS DMS não oferece suporte à replicação para uma tabela com um índice exclusivo criado com a função coalesce.
Se suas tabelas usarem sequências, atualize o valor de NEXTVAL para cada sequência no banco de dados de destino depois de interromper a replicação do banco de dados de origem. AWS DMS copia dados do seu banco de dados de origem, mas não migra sequências para o destino durante a replicação contínua.

Requisitos de segurança ao usar um banco de dados PostgreSQL como alvo para AWS Database Migration Service

Para fins de segurança, a conta de usuário usada para a migração de dados deve ser um usuário registrado em qualquer banco de dados PostgreSQL que você use como destino.

Seu endpoint de destino do PostgreSQL exige permissões mínimas de usuário para executar AWS DMS uma migração. Veja os exemplos a seguir.



    CREATE USER newuser WITH PASSWORD 'your-password';
    ALTER SCHEMA schema_name OWNER TO newuser;



    GRANT USAGE ON SCHEMA schema_name TO myuser;
    GRANT CONNECT ON DATABASE postgres to myuser;
    GRANT CREATE ON DATABASE postgres TO myuser;
    GRANT CREATE ON SCHEMA schema_name TO myuser;
    GRANT UPDATE, INSERT, SELECT, DELETE, TRUNCATE ON ALL TABLES IN SCHEMA schema_name TO myuser;
    GRANT TRUNCATE ON schema_name."BasicFeed" TO myuser;

Configurações de endpoint e atributos extras de conexão (ECAs) ao usar o PostgreSQL como destino para AWS DMS

Você pode usar configurações de endpoint e Atributos de Conexão Extra (ECAs) para configurar seu banco de dados de destino do PostgreSQL.

Você especifica as configurações ao criar o endpoint de destino usando o AWS DMS console ou usando o create-endpoint comando no AWS CLI, com a sintaxe --postgre-sql-settings '{"EndpointSetting": "value", ...}' JSON.

Você especifica ECAs usando o ExtraConnectionAttributes parâmetro para seu endpoint.

A tabela a seguir mostra as configurações de endpoint que é possível utilizar com o PostgreSQL como destino.

Nome	Descrição
`MaxFileSize`	Especifica o tamanho máximo (em KB) de um arquivo .csv usado para transferir dados para o PostgreSQL. Valor padrão: 32768 KB (32 MB) Valores válidos: 1 a 1.048.576 KB (até 1.1 GB) Exemplo: `--postgre-sql-settings '{"MaxFileSize": 512}'`
`ExecuteTimeout`	Define o tempo limite da instrução do cliente para a instância do PostgreSQL, em segundos. O valor padrão é de 60 segundos. Exemplo: `--postgre-sql-settings '{"ExecuteTimeout": 100}'`
`AfterConnectScript= SET session_replication_role = replica`	Esse atributo AWS DMS ignora chaves estrangeiras e acionadores de usuário para reduzir o tempo necessário para carregar dados em massa.
`MapUnboundedNumericAsString`	Esse parâmetro trata colunas com tipos de dados NUMERIC ilimitados como STRING para migrar com sucesso sem perder a precisão do valor numérico. Utilize esse parâmetro somente para replicação da origem do PostgreSQL para o destino do PostgreSQL ou bancos de dados compatíveis com o PostgreSQL. Valor padrão: falso Valores válidos: falso/verdadeiro Exemplo: `--postgre-sql-settings '{"MapUnboundedNumericAsString": "true"}` A utilização desse parâmetro pode resultar em alguma degradação do desempenho da replicação devido à transformação de numérico para string e de volta para numérico. Esse parâmetro é compatível para utilização pelo DMS versão 3.4.4 e superior nota Utilize `MapUnboundedNumericAsString` somente em endpoints de origem e de destino do PostgreSQL juntos. A utilização de `MapUnboundedNumericAsString` em endpoints PostgreSQL de origem restringe a precisão a 28 durante a CDC. A utilização de `MapUnboundedNumericAsString` em endpoints de destino migra os dados com Precisão 28 Escala 6. Não utilize `MapUnboundedNumericAsString` com destinos que não sejam do PostgreSQL.
`loadUsingCSV`	Use esse Atributo de Conexão Extra (ECA) para transferir dados para operações de carga total usando o comando\ COPY. Valor padrão: `true` Valores válidos: verdadeiro/falso Exemplo de ECA: `loadUsingCSV=true;` Observação: definir esse ECA como falso pode resultar em alguma degradação do desempenho da replicação devido aos INSERTs serem executados diretamente.
`DatabaseMode`	Utilize esse atributo para alterar o comportamento padrão do tratamento da replicação de endpoints compatíveis com PostgreSQL que exigem alguma configuração adicional, como os endpoints do Babelfish. Valor padrão: `DEFAULT` Valores válidos: `DEFAULT`, `BABELFISH` Exemplo: `DatabaseMode=default;`
`BabelfishDatabaseName`	Utilize esse atributo para especificar o nome do banco de dados Babelfish T-SQL de destino que está sendo migrado. Isso será obrigatório se `DatabaseMode` estiver definido como `Babelfish`. Esse não é o banco de dados `babelfish_db` reservado. Exemplo: `BabelfishDatabaseName=TargetDb;`

Tipos de dados de destino do PostgreSQL

O endpoint do banco de dados PostgreSQL é AWS DMS compatível com a maioria dos tipos de dados do banco de dados PostgreSQL. A tabela a seguir mostra os tipos de dados de destino do banco de dados PostgreSQL que são compatíveis com o AWS DMS uso e o mapeamento AWS DMS padrão dos tipos de dados.

Para obter informações adicionais sobre tipos de AWS DMS dados, consulteTipos de dados do AWS Database Migration Service.

AWS DMS tipo de dados	Tipo de dados do PostgreSQL
BOOLEAN	BOOLEAN
BLOB	BYTEA
BYTES	BYTEA
DATA	DATA
TIME	TIME
DATETIME	Se a escala for de 0 a 6, use TIMESTAMP. Se a escala for de 7 a 9, use VARCHAR (37).
INT1	SMALLINT
INT2	SMALLINT
INT4	INTEGER
INT8	BIGINT
NUMERIC	DECIMAL (P,S)
REAL4	FLOAT4
REAL8	FLOAT8
STRING	Se o tamanho for de 1 a 21.845, use VARCHAR (tamanho em bytes). Se o tamanho for de 21.846 a 2.147.483.647, use VARCHAR (65535).
UINT1	SMALLINT
UINT2	INTEGER
UINT4	BIGINT
UINT8	BIGINT
WSTRING	Se o tamanho for de 1 a 21.845, use VARCHAR (tamanho em bytes). Se o tamanho for de 21.846 a 2.147.483.647, use VARCHAR (65535).
NCLOB	TEXT
CLOB	TEXT

nota

Ao replicar de uma fonte do PostgreSQL AWS DMS , cria a tabela de destino com os mesmos tipos de dados para todas as colunas, exceto as colunas com tipos de dados definidos pelo usuário. Nesses casos, o tipo de dados é criado como "variante de caractere" no destino.

Usando o Babelfish para Aurora PostgreSQL como alvo para AWS Database Migration Service

É possível migrar as tabelas de origem do SQL Server para um destino do Babelfish para Amazon Aurora PostgreSQL utilizando o AWS Database Migration Service. Com o Babelfish, o Aurora PostgreSQL compreende o dialeto do T-SQL, do SQL proprietário do Microsoft SQL Server, e é compatível com o mesmo protocolo de comunicação. Portanto, as aplicações escritas para o SQL Server agora podem funcionar com o Aurora com menos alterações no código. O recurso Babelfish está incorporado ao Amazon Aurora sem custo adicional. É possível ativar o Babelfish no cluster do Amazon Aurora no console do Amazon RDS.

Ao criar seu endpoint de AWS DMS destino usando os comandos do AWS DMS console, da API ou da CLI, especifique o mecanismo de destino como Amazon Aurora PostgreSQL e nomeie o banco de dados como babelfish_db. Na seção Configurações de endpoint, adicione configurações para definir DatabaseMode como Babelfish e BabelfishDatabaseName para o nome do banco de dados Babelfish T-SQL de destino.

Adicionar regras de transformação à tarefa de migração

Ao definir uma tarefa de migração para um destino do Babelfish, inclua regras de transformação que garantam que o DMS utilize as tabelas T-SQL do Babelfish pré-criadas no banco de dados de destino.

Primeiro, adicione uma regra de transformação à tarefa de migração que coloque todos os nomes das tabelas em letras minúsculas. O Babelfish armazena em letras minúsculas no pg_class catálogo do PostgreSQL os nomes das tabelas que você cria utilizando o T-SQL. No entanto, quando você tem tabelas do SQL Server com nomes em maiúsculas e minúsculas, o DMS cria as tabelas utilizando tipos de dados nativos do PostgreSQL em vez dos tipos de dados compatíveis com T-SQL. Por esse motivo, adicione uma regra de transformação que torne todos os nomes de tabelas em minúsculas. Observe que os nomes de coluna não devem ser mudados para minúsculas.

Se você utilizou o modo de migração de vários bancos de dados ao definir o cluster, adicione uma regra de transformação que renomeia o esquema original do SQL Server. Renomeie o esquema do SQL Server para incluir o nome do banco de dados T-SQL. Por exemplo, se o nome do esquema original do SQL Server for dbo e o nome do banco de dados T-SQL for mydb, renomeie o esquema para mydb_dbo utilizando uma regra de transformação.

Se você utilizar o modo de banco de dados único, não será necessária uma regra de transformação para renomear os esquemas. Os nomes dos esquemas têm um one-to-one mapeamento com o banco de dados T-SQL de destino no Babelfish.

O exemplo de regra de transformação a seguir torna todos os nomes de tabelas em minúsculas e renomeia o esquema original do SQL Server de dbo para mydb_dbo.


{
   "rules": [
   {
      "rule-type": "transformation",
      "rule-id": "566251737",
      "rule-name": "566251737",
      "rule-target": "schema",
      "object-locator": {
         "schema-name": "dbo"
      },
      "rule-action": "rename",
      "value": "mydb_dbo",
      "old-value": null
   },
   {
      "rule-type": "transformation",
      "rule-id": "566139410",
      "rule-name": "566139410",
      "rule-target": "table",
      "object-locator": {
         "schema-name": "%",
         "table-name": "%"
      },
      "rule-action": "convert-lowercase",
      "value": null,
      "old-value": null
   },
   {
      "rule-type": "selection",
      "rule-id": "566111704",
      "rule-name": "566111704",
      "object-locator": {
         "schema-name": "dbo",
         "table-name": "%"
      },
      "rule-action": "include",
      "filters": []
   }
]
}

Limitações ao utilizar um endpoint de destino do PostgreSQL com tabelas do Babelfish

As limitações a seguir se aplicam ao utilizar um endpoint de destino do PostgreSQL com tabelas do Babelfish:

Para o modo Preparação da tabela de destino, use somente os modos Não fazer nada ou Truncar. Não utilize o modo Abandonar tabelas no destino. Nesse modo, o DMS cria as tabelas como tabelas do PostgreSQL que o T-SQL talvez não reconheça.
AWS DMS não suporta o tipo de dados sql_variant.
O Babelfish não é compatível com os tipos de dados HEIRARCHYID, GEOMETRY e GEOGRAPHY. Para migrar esses tipos de dados, é possível adicionar regras de transformação para converter o tipo de dados em wstring(250).
O Babelfish é compatível com a migração de tipos de dados BINARY, VARBINARY e IMAGE utilizando o tipo de dados BYTEA. Em versões anteriores do Aurora PostgreSQL, é possível utilizar o DMS para migrar essas tabelas para um Endpoint de destino do Babelfish. Não é necessário especificar um tamanho para o tipo de dados BYTEA, conforme mostrado no exemplo a seguir.
```
[Picture] [VARBINARY](max) NULL
```
Altere o tipo de dados T-SQL anterior para o tipo de dados T-SQL compatível BYTEA.
```
[Picture] BYTEA NULL
```
Para versões anteriores do Aurora PostgreSQL Babelfish, se você criar uma tarefa de migração para replicação contínua do SQL Server para o Babelfish utilizando endpoint de destino do PostgreSQL, precisará atribuir o tipo de dados SERIAL a qualquer tabela que utilize colunas IDENTITY. Desde o Aurora PostgreSQL (versão 15.3/14.8 e superior) e do Babelfish (versão 3.2.0 e superior), a coluna de identidade é compatível e não é mais necessário atribuir o tipo de dados SERIAL. Para obter mais informações, consulte Utilizar SERIAL na seção Sequências e identidade do Manual de migração do SQL Server para o Aurora PostgreSQL. Crie a tabela no Babelfish, altere a definição da coluna da seguinte forma.
```
    [IDCol] [INT] IDENTITY(1,1) NOT NULL PRIMARY KEY
```
Altere a anterior para a seguinte.
```
    [IDCol] SERIAL PRIMARY KEY
```
O Aurora PostgreSQL compatível com o Babelfish cria uma sequência utilizando a configuração padrão e adiciona uma restrição NOT NULL à coluna. A sequência recém-criada se comporta como uma sequência normal (incrementada em 1) e não tem a opção de SERIAL composta.

Depois de migrar dados com tabelas que utilizam colunas IDENTITY ou o tipo de dados SERIAL, redefina o objeto de sequência baseado em PostgreSQL com base no valor máximo da coluna. Depois de executar uma carga máxima das tabelas, utilize a consulta T-SQL a seguir para gerar instruções para definir o seed do objeto de sequência associado.


DECLARE @schema_prefix NVARCHAR(200) = ''

IF current_setting('babelfishpg_tsql.migration_mode') = 'multi-db'
        SET @schema_prefix = db_name() + '_'

SELECT 'SELECT setval(pg_get_serial_sequence(''' + @schema_prefix + schema_name(tables.schema_id) + '.' + tables.name + ''', ''' + columns.name + ''')
               ,(select max(' + columns.name + ') from ' + schema_name(tables.schema_id) + '.' + tables.name + '));'
FROM sys.tables tables
JOIN sys.columns columns ON tables.object_id = columns.object_id
WHERE columns.is_identity = 1

UNION ALL

SELECT 'SELECT setval(pg_get_serial_sequence(''' + @schema_prefix + table_schema + '.' + table_name + ''', 
''' + column_name + '''),(select max(' + column_name + ') from ' + table_schema + '.' + table_name + '));'
FROM information_schema.columns
WHERE column_default LIKE 'nextval(%';

A consulta gera uma série de instruções SELECT que você executa para atualizar os valores máximos de IDENTITY e SERIAL.

Em versões do Babelfish anteriores à 3.2, o Modo LOB completo pode resultar em um erro de tabela. Se isso acontecer, crie uma tarefa separada para as tabelas que falharam no carregamento. Utilize o Modo LOB limitado para especificar o valor apropriado para o Tamanho máximo de LOB (KB). Outra opção é definir a configuração do atributo de conexão ForceFullLob=True do endpoint do SQL Server.
Para versões do Babelfish anteriores à 3.2, a execução da validação de dados com tabelas do Babelfish que não utilizam chaves primárias baseadas em números inteiros gera uma mensagem de que uma chave exclusiva adequada não pode ser encontrada. Desde o Aurora PostgreSQL (versão 15.3/14.8 e superior) e do Babelfish (versão 3.2.0 e superior), a validação de dados para chaves primárias de número não inteiro é compatível.

Devido às diferenças de precisão no número de casas decimais de segundos, o DMS relata falhas na validação de dados para tabelas do Babelfish que utilizam tipos de dados DATETIME. Para suprimir essas falhas, é possível adicionar o seguinte tipo de regra de validação para os tipos de dados DATETIME.


{
         "rule-type": "validation",
         "rule-id": "3",
         "rule-name": "3",
         "rule-target": "column",
         "object-locator": {
             "schema-name": "dbo",
             "table-name": "%",
             "column-name": "%",
             "data-type": "datetime"
         },
         "rule-action": "override-validation-function",
         "source-function": "case when ${column-name} is NULL then NULL else 0 end",
         "target-function": "case when ${column-name} is NULL then NULL else 0 end"
     }

Atenção O Javascript está desativado ou não está disponível no seu navegador.

Para usar a documentação da AWS, o Javascript deve estar ativado. Consulte as páginas de Ajuda do navegador para obter instruções.

Convenções do documento

Utilizar o SQL Server como destino

Usar o MySQL como destino