Configuração de replicação para o Snowflake Connector for MySQL¶

Como adicionar uma fonte de dados¶

Uma fonte de dados é a representação de um único servidor MySQL. O Snowflake Connector for MySQL pode replicar dados de diversas fontes de dados. Antes de iniciar a replicação, você precisa adicionar pelo menos uma fonte de dados.

O Snowflake Connector for MySQL replica dados de cada fonte de dados para um banco de dados de destino distinto no Snowflake. O mesmo banco de dados de destino não pode ser usado por várias fontes de dados.

Para adicionar uma fonte de dados, execute o seguinte comando:

CALL PUBLIC.ADD_DATA_SOURCE('<data_source_name>', '<dest_db>');

Copy

Onde:

data_source_name

Especifica o nome exclusivo da fonte de dados. O nome deve corresponder ao nome de uma fonte de dados definida na configuração do agente. Certifique-se de que o nome escolhido esteja em conformidade com os seguintes requisitos:

• O nome contém apenas letras maiúsculas (A–Z) e dígitos decimais (0–9).

• O nome não pode ter mais de 50 caracteres.

dest_db

Especifica o nome do banco de dados de destino no Snowflake. Se o banco de dados não existir, o procedimento o criará automaticamente. Caso contrário, o conector usa um banco de dados existente. Nesse caso, você deve conceder privilégios no banco de dados ao conector antes de adicionar uma fonte de dados.

Nota

Uma vez adicionada, uma fonte de dados não pode ser renomeada ou removida.

Como adicionar outras fontes de dados¶

É possível adicionar novas fontes de dados a qualquer momento. Para adicionar uma nova fonte de dados enquanto o agente já estiver em execução, faça o seguinte:

1. Adicione uma fonte de dados.

2. Certifique-se de que o agente esteja parado.

3. Configure a conexão do agente com a nova fonte de dados.

4. Execute o contêiner Docker do agente.

Como adicionar uma tabela de origem para replicação¶

Para adicionar tabelas de origem para replicação, execute o seguinte comando:

CALL PUBLIC.ADD_TABLES('<data_source_name>', '<schema_name>', <table_names_array>);

Copy

Onde:

data_source_name

Especifica o nome da fonte de dados com a tabela de origem.

schema_name

Especifica o nome do esquema da tabela de origem.

table_names_array

Especifica a matriz de nomes de tabela:

ARRAY_CONSTRUCT('<table_name>', '<other_table_name>', ...)

Como adicionar uma tabela de origem com os seguintes efeitos:

• schema_name e table_name são usados como nome do esquema e nome da tabela, respectivamente, para replicar dados de origem do banco de dados de origem.

Como adicionar uma tabela de origem com filtros de coluna¶

Para adicionar uma tabela de origem com colunas filtradas, execute o seguinte comando:

CALL PUBLIC.ADD_TABLE_WITH_COLUMNS('<data_source_name>', '<schema_name>', '<table_name>', <included_columns_array>, <excluded_columns_array>);

Copy

Onde:

data_source_name

Especifica o nome da fonte de dados com a tabela de origem.

schema_name

Especifica o nome do esquema da tabela de origem.

table_name

Especifica o nome da tabela de origem.

included_columns

Especifica a matriz de nomes de colunas que devem ser replicadas:

ARRAY_CONSTRUCT('<column_name>', '<other_column_name>', ...)

excluded_columns

Especifica a matriz de nomes de colunas que devem ser ignoradas:

ARRAY_CONSTRUCT('<column_name>', '<other_column_name>', ...)

As seguintes regras se aplicam ao procedimento acima:

• A filtragem ocorre antes que os dados sejam ingeridos no Snowflake – somente os dados das colunas escolhidas são transmitidos para o Snowflake em cargas instantâneas e incrementais.

• included_columns e excluded_columns são apenas máscaras. Dessa forma, o conector não gerará um erro se a coluna especificada não existir. A máscara para a coluna inexistente será simplesmente ignorada.

• Você não deve fornecer included_columns e excluded_columns. Se você quiser listar included_columns, você deve deixar excluded_columns vazio e vice-versa.

• Se ambas as matrizes não estiverem vazias e não houver colunas conflitantes, included_columns terá precedência sobre excluded_columns.

• Se uma coluna aparecer em included_columns e excluded_columns, o procedimento gerará um erro.

• Se included_columns e excluded_columns forem matrizes vazias, todas as colunas disponíveis serão ingeridas.

• Independentemente da configuração, as colunas de chave primária sempre são replicadas.

Por exemplo, vamos supor que temos uma tabela de origem com as colunas fornecidas: A, B, C e D, onde A é uma coluna de chave primária, então:

Remoção de uma tabela da replicação¶

Para remover uma tabela de origem da replicação, execute o seguinte comando:

CALL PUBLIC.REMOVE_TABLE('<data_source_name>', '<schema_name>', '<table_name>');

Onde:

data_source_name

Especifica o nome da fonte de dados com a tabela de origem.

schema_name

Especifica o nome do esquema da tabela de origem.

table_name

Especifica o nome da tabela de origem.

Neste ponto, a tabela de destino ainda é propriedade do aplicativo conector. Se você deseja remover ou modificar a tabela de destino, primeiro precisa transferir sua propriedade para uma função em sua conta. Execute a seguinte consulta como ACCOUNTADMIN:

GRANT OWNERSHIP ON TABLE <destination_database_name>.<schema_name>.<table_name>
  TO ROLE <role_name>
  REVOKE CURRENT GRANTS;

Configuração da replicação agendada¶

O conector pode replicar dados em dois modos: contínuo ou programado. O padrão é um modo contínuo.

O modo contínuo replica os dados o mais rápido possível. Exige a execução de um warehouse operacional 24 horas por dia, 7 dias por semana, o que pode gerar custos desnecessários, mesmo sem uma replicação contínua.

O modo agendado replica dados de acordo com um cronograma configurado. O objetivo é reduzir os custos de replicação quando não há necessidade de replicar dados continuamente ou o volume de dados é pequeno (fazendo com que o conector fique em estado ocioso a maior parte do tempo).

O modo agendado introduz o conceito de conclusão de replicação. A replicação do instantâneo começa quando a execução da consulta de SELECT <colunas> FROM <TABLE> é iniciada e termina quando os dados são replicados na tabela de destino. A replicação incremental começa a partir do ponteiro de captura de dados de alteração (CDC) armazenado anteriormente, mas não tem um final, pois os dados são ingeridos continuamente. Portanto, o conector replica dados do ponteiro CDC armazenado anteriormente até o ponteiro CDC mais recente (determinado no início da replicação). Dessa forma, o conector garante a conclusão da replicação em modo agendado.

O modo agendado reduz os custos de replicação ao suspender o warehouse operacional. O warehouse pode ser suspenso se a replicação de cada tabela de origem for concluída. O warehouse permanece suspenso até a próxima execução da replicação, de acordo com o cronograma.

Para habilitar o modo agendado, execute o seguinte comando:

CALL PUBLIC.ENABLE_SCHEDULED_REPLICATION('<data_source_name>', '<schedule>');

Copy

Onde:

data_source_name

Especifica o nome da fonte de dados.

schedule

Especifica o cronograma ou a frequência na qual o conector executa a replicação da fonte de dados. A frequência mínima permitida é de 10 minutos. Para obter mais detalhes sobre como especificar o cronograma ou a frequência, consulte o parâmetro SCHEDULE.

Exemplos de cronograma:

• 60 MINUTE

  Agenda a replicação a cada 60 minutos.

• USING CRON 0 2 * * * UTC

  Agenda a replicação para as 2 da manhã UTC diariamente.

Para desabilitar o modo agendado, execute o seguinte comando:

CALL PUBLIC.DISABLE_SCHEDULED_REPLICATION('<data_source_name>');

Copy

Onde:

data_source_name

Especifica o nome da fonte de dados.

Para verificar o cronograma atual, consulte Exibição de fontes de dados.

Próximos passos¶

Após completar estes procedimentos, siga os passos em Visualização de dados MySQL no Snowflake.