Sobre a Openflow Connector for SQL Server¶

Replicação de dados¶

O conector oferece suporte à replicação de tabelas de vários bancos de dados de servidor SQL em uma única instância do servidor SQL. O conector cria tabelas replicadas de diferentes bancos de dados em esquemas separados no banco de dados Snowflake de destino.

Referencie as tabelas replicadas combinando o nome do banco de dados de origem, o nome do esquema de origem e o nome da tabela no formato a seguir:

<database_name>.<schema_name>.<table_name>

Para cada esquema em cada banco de dados de origem replicado, o conector cria um esquema separado no banco de dados Snowflake de destino. O nome do esquema de destino é uma combinação do nome do banco de dados de origem e do nome do esquema de origem, separados por um caractere de sublinhado (_), conforme mostrado no exemplo a seguir:

<source_database_name>_<source_schema_name>

O conector cria tabelas no esquema de destino com o mesmo nome do nome da tabela de origem, conforme mostrado no exemplo a seguir:

<destination_database>_<destination_schema_name>.<source_table_name>

Como as tabelas são replicadas¶

O conector replica tabelas nas seguintes áreas de preparação:

1. Introspecção de esquema: o conector descobre as colunas na tabela de origem, incluindo os nomes e tipos de coluna, e as valida em relação às limitações do Snowflake e do conector. O conector descobre as colunas da tabela de origem, incluindo os nomes e os tipos de colunas, e as valida de acordo com as limitações do Snowflake e do conector. Após a conclusão bem-sucedida desse estágio, o conector cria uma tabela de destino vazia.

2. Carga de instantâneo: o conector copia todos os dados disponíveis na tabela de origem para a tabela de destino. Se esse estágio falhar, nenhum outro dado será replicado. Se este estágio falhar, o conector deixará de replicar os dados. Após a conclusão bem-sucedida, os dados da tabela de origem estarão disponíveis na tabela de destino.

3. Carga incremental: o conector rastreia as alterações na tabela de origem e aplica essas alterações à tabela de destino. Esse processo continua até que a tabela seja removida da replicação. A falha nesse estágio interrompe permanentemente a replicação da tabela de origem, até que o problema seja resolvido.

Para obter informações de como ignorar o carregamento de instantâneos e usar o processo de carregamento incremental, consulte Replicação incremental.

Status da replicação da tabela¶

Falhas temporárias, como erros de conexão, não impedem a replicação das tabelas. Entretanto, falhas permanentes, como tipos de dados incompatíveis, impedem a replicação das tabelas.

Para solucionar problemas de replicação ou verificar se uma tabela foi removida com êxito do fluxo de replicação, consulte o armazenamento de estado de tabela:

1. Na tela do tempo de execução do Openflow, clique com o botão direito do mouse em um grupo de processadores e escolha Controller Services. Uma tabela que lista os serviços do controlador é exibida.

2. Localize a linha chamada Table State Store, clique no botão More à direita da linha e escolha View State.

Uma lista de tabelas e os respectivos estados atuais é exibida. Digite na caixa de pesquisa para filtrar a lista por nome da tabela. Os estados possíveis são:

• NEW: a tabela está agendada para replicação, mas a replicação não foi iniciada.

• SNAPSHOT_REPLICATION: o conector está copiando os dados existentes. Esse status é exibido até que todos os registros sejam armazenados na tabela de destino.

• INCREMENTAL_REPLICATION: o conector está replicando as alterações ativamente. Esse status é exibido após o término da replicação do instantâneo e continua a ser exibido indefinidamente até que uma tabela seja removida da replicação ou a replicação falhe.

• FAILED: a replicação foi interrompida permanentemente devido a um erro.

Replication state for table <database_name>.<schema_name>.<table_name> changed from <old_state> to <new_state>

Se uma falha permanente impedir a replicação da tabela, remova a tabela da replicação. Depois de resolver o problema que causou a falha, você poderá adicionar a tabela de volta à replicação. Para obter mais informações, consulte Reiniciar a replicação da tabela.

Colunas de metadados da tabela de destino¶

Cada tabela de destino inclui as seguintes colunas de metadados que rastreiam informações de replicação:

Linhas excluídas logicamente¶

Quando uma linha é excluída da tabela de origem, o conector não a remove fisicamente da tabela de destino. Em vez disso, a linha é marcada como excluída definindo a coluna de metadados _SNOWFLAKE_DELETED como true.

Essa abordagem permite:

• Reter dados históricos para fins de auditoria ou conformidade.

• Consultar registros excluídos quando necessário.

• Decidir quando e como remover dados permanentemente com base em suas necessidades.

Para consultar apenas linhas ativas (não excluídas), filtre pela coluna _SNOWFLAKE_DELETED:

SELECT * FROM my_table WHERE _SNOWFLAKE_DELETED = FALSE;

Para consultar linhas excluídas:

SELECT * FROM my_table WHERE _SNOWFLAKE_DELETED = TRUE;

Colunas removidas¶

Quando uma coluna é removida da tabela de origem, o conector não remove a coluna correspondente da tabela de destino. Em vez disso, a coluna é renomeada com a adição do sufixo __SNOWFLAKE_DELETED para preservar os valores históricos.

Por exemplo, se uma coluna chamada EMAIL for removida da tabela de origem, ela será renomeada para EMAIL__SNOWFLAKE_DELETED na tabela de destino. As linhas que existiam antes da remoção da coluna mantêm os valores originais, enquanto as linhas adicionadas após a remoção terão NULL nessa coluna.

Você ainda pode consultar os valores históricos da coluna renomeada:

SELECT EMAIL__SNOWFLAKE_DELETED FROM my_table;

Colunas renomeadas¶

Devido às limitações nos mecanismos de captura de dados de alteração (change data capture, CDC), o conector não consegue distinguir entre uma coluna sendo renomeada e uma coluna sendo removida seguida da adição de uma nova coluna. Como resultado, quando você renomeia uma coluna na tabela de origem, o conector trata isso como duas operações separadas: remover a coluna original e adicionar uma nova coluna com o novo nome.

Por exemplo, se você renomear uma coluna de A para B na tabela de origem, a tabela de destino conterá:

• A__SNOWFLAKE_DELETED: contém valores de antes da renomeação. As linhas adicionadas após a renomeação têm NULL nesta coluna.

• B: contém valores de depois da renomeação. As linhas que existiam antes da renomeação têm NULL nesta coluna.

SELECT
    COALESCE(B, A__SNOWFLAKE_DELETED) AS A_RENAMED_TO_B
FROM my_table;

SELECT
    CASE
        WHEN B IS NOT NULL THEN B
        ELSE A__SNOWFLAKE_DELETED
    END AS A_RENAMED_TO_B
FROM my_table;

CREATE VIEW my_table_unified AS
SELECT
    *,
    COALESCE(B, A__SNOWFLAKE_DELETED) AS A_RENAMED_TO_B
FROM my_table;

Tabelas de registro¶

Durante a replicação incremental, as alterações do banco de dados de origem são gravadas primeiro em tabelas de registro antes de serem mescladas às tabelas de destino. O conector não remove automaticamente os dados das tabelas de registro, pois esses dados podem ser úteis para fins de auditoria, depuração ou reprocessamento.

As tabelas de registro são criadas no mesmo esquema que as respectivas tabelas de destino e seguem esta convenção de nomenclatura:

<TABLE_NAME>_JOURNAL_<timestamp>_<number>

Onde:

• <TABLE_NAME> é o nome da tabela de destino.

• <timestamp> é o carimbo de data/hora de criação no formato Unix (segundos desde 1º de janeiro de 1970), garantindo a exclusividade.

• <number> começa em 1 e incrementa sempre que o esquema da tabela de destino é alterado, seja devido a alterações no esquema da tabela de origem ou a modificações nos filtros de coluna.

Por exemplo, se a tabela de destino for SALES.ORDERS, a tabela de registro poderá ter o nome SALES.ORDERS_JOURNAL_1705320000_1.