Introdução às transferências de dados do MySQL

É possível carregar dados do MySQL para o BigQuery usando o serviço de transferência de dados do BigQuery para o conector do MySQL. O conector oferece suporte a instâncias do MySQL hospedadas no ambiente local, no Cloud SQL e em outros provedores de nuvem pública, como Amazon Web Services (AWS) e Microsoft Azure. Este documento oferece uma visão geral das opções de ingestão de dados para a transferência do MySQL e informações sobre mapeamento de tipo de dados e preços.

Para saber como programar uma transferência do MySQL, consulte Carregar dados do MySQL no BigQuery.

Opções de ingestão de dados

As seções a seguir fornecem informações sobre as opções de ingestão de dados ao configurar uma transferência de dados do MySQL.

Configuração de TLS

O conector do MySQL oferece suporte à configuração de segurança de camada de transporte (TLS) para criptografar as transferências de dados para o BigQuery. O conector do MySQL oferece suporte às seguintes configurações de TLS:

  • O modo Criptografar dados e verificar a AC e o nome do host. Esse modo realiza uma validação completa do servidor usando TLS no protocolo TCPS. Ele criptografa todos os dados em trânsito e verifica se o certificado do servidor de banco de dados está assinado por uma autoridade de certificação (AC) confiável. Esse modo também verifica se o nome do host ao qual você está se conectando corresponde exatamente ao nome comum (CN) ou a um nome alternativo do titular (SAN) no certificado do servidor. Esse modo impede que invasores usem um certificado válido para um domínio diferente para se passar pelo servidor de banco de dados.

    Se o nome do host não corresponder ao CN ou SAN do certificado, a conexão falhará. É necessário configurar uma resolução de DNS para corresponder ao certificado ou usar um modo de segurança diferente. Use esse modo para a opção mais segura de evitar ataques man-in-the-middle (MITM).

  • O modo Criptografar dados e verificar apenas a AC. Esse modo criptografa todos os dados usando TLS no protocolo TCPS e verifica se o certificado do servidor está assinado por uma AC em que o cliente confia. No entanto, esse modo não verifica o nome do host do servidor. Esse modo se conecta com sucesso, desde que o certificado seja válido e emitido por uma AC confiável, independentemente de o nome do host no certificado corresponder ao nome do host ao qual você está se conectando.

    Use esse modo se quiser garantir que você esteja se conectando a um servidor cujo certificado seja assinado por uma AC confiável, mas o nome do host não seja verificável ou você não tenha controle sobre a configuração do nome do host.

  • O modo Somente criptografia. Esse modo criptografa todos os dados transferidos entre o cliente e o servidor. Ele não realiza nenhuma validação de certificado ou nome do host.

    Esse modo oferece algum nível de segurança ao proteger os dados em trânsito, mas pode ser vulnerável a ataques MITM.

    Use esse modo se precisar garantir que todos os dados sejam criptografados, mas não puder ou não quiser verificar a identidade do servidor. Recomendamos usar esse modo ao trabalhar com VPCs particulares.

  • O modo Sem criptografia ou verificação. Esse modo não criptografa nenhum dado e não realiza nenhuma verificação de certificado ou nome do host. Todos os dados são enviados como texto simples.

    Não recomendamos o uso desse modo em um ambiente em que dados sensíveis são processados. Recomendamos usar esse modo apenas para fins de teste em uma rede isolada em que a segurança não seja uma preocupação.

Certificado de servidor confiável (do tipo PEM)

Se você estiver usando o modo Criptografar dados e verificar a AC e o nome do host ou o modo Criptografar dados e verificar a AC , também poderá fornecer um ou mais certificados codificados em PEM. Esses certificados são necessários em alguns cenários em que o serviço de transferência de dados do BigQuery precisa verificar a identidade do servidor de banco de dados durante a conexão TLS:

  • Se você estiver usando um certificado assinado por uma AC particular na sua organização ou um certificado autoassinado, forneça a cadeia de certificados completa ou o certificado autoassinado único. Isso é necessário para certificados emitidos por ACs internas de serviços de provedores de nuvem gerenciados, como o Amazon Banco de Dados Relacional (RDS).
  • Se o certificado do servidor de banco de dados for assinado por uma AC pública (por exemplo, Let's Encrypt, DigiCert ou GlobalSign), não será necessário fornecer um certificado. Os certificados raiz dessas ACs públicas são pré-instalados e confiáveis pelo serviço de transferência de dados do BigQuery.

É possível especificar certificados codificados em PEM no campo Certificado PEM confiável na configuração de transferência, com os seguintes requisitos:

  • O certificado precisa ser uma cadeia de certificados válida codificada em PEM.
  • O certificado precisa estar totalmente correto. Qualquer certificado ausente na cadeia ou conteúdo incorreto faz com que a conexão TLS falhe.
  • Para um único certificado, é possível fornecer um certificado autoassinado único do servidor de banco de dados.
  • Para uma cadeia de certificados completa emitida por uma AC particular, é necessário fornecer a cadeia de confiança completa. Isso inclui o certificado do servidor de banco de dados e todos os certificados de AC intermediários e raiz.

Transferências completas ou incrementais

É possível especificar como os dados são carregados no BigQuery selecionando a preferência de gravação Completa ou Incremental na configuração de transferência ao configurar uma transferência do MySQL. As transferências incrementais são aceitas na versão pré-lançamento Preview.

É possível configurar uma transferência de dados completa para transferir todos os dados dos conjuntos de dados do MySQL com cada transferência de dados.

Como alternativa, é possível configurar uma transferência de dados incremental (versão pré-lançamento) para transferir apenas os dados que foram alterados desde a última transferência de dados, em vez de carregar todo o conjunto de dados com cada transferência de dados. Se você selecionar Incremental para a transferência de dados, especifique os modos de gravação Adicionar ou Upsert para definir como os dados são gravados no BigQuery durante uma transferência de dados incremental. As seções a seguir descrevem os modos de gravação disponíveis.

Modo de gravação "Adicionar"

O modo de gravação "Adicionar ao final" insere apenas novas linhas na tabela de destino. Essa opção anexa estritamente os dados transferidos sem verificar os registros existentes. Portanto, esse modo pode causar duplicação de dados na tabela de destino.

Ao selecionar o modo de anexação, é necessário selecionar uma coluna de marca d'água. Uma coluna de marca d'água é necessária para que o conector do MySQL rastreie as mudanças na tabela de origem.

Para transferências do MySQL, recomendamos selecionar uma coluna que seja atualizada apenas quando o registro for criado e não seja alterada com atualizações subsequentes, por exemplo, a coluna CREATED_AT.

Modo de gravação "Upsert"

O modo de gravação "Upsert" atualiza uma linha ou insere uma nova linha na tabela de destino verificando uma chave primária. É possível especificar uma chave primária para permitir que o conector do MySQL determine quais mudanças são necessárias para manter a tabela de destino atualizada com a tabela de origem. Se a chave primária especificada estiver presente na tabela de destino do BigQuery durante uma transferência de dados, o conector do MySQL atualizará essa linha com novos dados da tabela de origem. Se uma chave primária não estiver presente durante uma transferência de dados, o conector do MySQL inserirá uma nova linha.

Ao selecionar o modo "Upsert", é necessário selecionar uma coluna de marca d'água e uma chave primária:

  • Uma coluna de marca d'água é necessária para que o conector do MySQL rastreie as mudanças na tabela de origem.
    • Selecione uma coluna de marca d'água que seja atualizada sempre que uma linha for modificada. Recomendamos colunas semelhantes à coluna UPDATED_AT ou LAST_MODIFIED.

  • A chave primária pode ser uma ou mais colunas na tabela necessárias para que o conector do MySQL determine se precisa inserir ou atualizar uma linha.

    Selecione colunas que contenham valores não nulos exclusivos em todas as linhas da tabela. Recomendamos colunas que incluam identificadores gerados pelo sistema, códigos de referência exclusivos (por exemplo, IDs de incremento automático) ou IDs de sequência imutáveis baseados em tempo.

    Para evitar possível perda ou corrupção de dados, as colunas de chave primária selecionadas precisam ter valores exclusivos. Se você tiver dúvidas sobre a exclusividade da coluna de chave primária escolhida, recomendamos que use o modo de gravação "Adicionar".

Comportamento de ingestão incremental

Quando você faz mudanças no esquema da tabela na fonte de dados, as transferências de dados incrementais dessas tabelas são refletidas no BigQuery das seguintes maneiras:

Mudanças na fonte de dados Comportamento de ingestão incremental
Adicionar uma nova coluna Uma nova coluna é adicionada à tabela do BigQuery de destino. Todos os registros anteriores dessa coluna terão valores nulos.
Excluir uma coluna A coluna excluída permanece na tabela de destino do BigQuery. Novas entradas nessa coluna excluída são preenchidas com valores nulos.
Mudar o tipo de dados em uma coluna O conector oferece suporte apenas a conversões de tipo de dados compatíveis com a instrução DDL ALTER COLUMN. Qualquer outra conversão de tipo de dados faz com que a transferência de dados falhe.

Se você encontrar algum problema, recomendamos criar uma nova configuração de transferência.
Renomear uma coluna A coluna original permanece na tabela de destino do BigQuery como está, enquanto uma nova coluna é adicionada à tabela de destino com o nome atualizado.

Mapeamento de tipo de dados

A tabela a seguir mapeia os tipos de dados do MySQL para os tipos de dados correspondentes do BigQuery:

Tipo de dados do MySQL Tipo de dados do BigQuery Tipo de dados atualizado do BigQuery
BIT BOOLEAN
TINYINT INTEGER
BOOL, BOOLEAN INTEGER

Em um banco de dados MySQL, os tipos de dados BOOL e BOOLEAN são armazenados internamente como TINYINT(1), que oferece suporte a valores no intervalo -128 a 127. Por esse motivo, BOOL e BOOLEAN tipos de dados são mapeados para INTEGER quando transferidos para o BigQuery. Para mais informações, consulte Sintaxe de tipo de dados numérico.
SMALLINT INTEGER
MEDIUMINT INTEGER
INT, INTEGER INTEGER
BIGINT BIGNUMERIC
FLOAT FLOAT
DOUBLE FLOAT
DECIMAL BIGNUMERIC
DATE DATE
DATETIME TIMESTAMP DATETIME
TIMESTAMP TIMESTAMP
TIME TIME
YEAR DATE
CHAR STRING
VARCHAR STRING
BINARY BYTES
VARBINARY BYTES
TINYBLOB BYTES
TINYTEXT STRING
BLOB BYTES
TEXT STRING
MEDIUMBLOB BYTES
MEDIUMTEXT STRING
LONGBLOB BYTES
LONGTEXT STRING
ENUM STRING
SET STRING
JSON STRING JSON
GEOMETRY BYTES GEOGRAPHY

Preços

Para informações de preços sobre transferências do MySQL, consulte Preços do serviço de transferência de dados.

A seguir