O conector CDC do MySQL permite ler dados de instantâneos e dados incrementais do banco de dados MySQL.
Este documento traduz como configurar o conector CDC do MySQL para executar consultas SQL no banco de dados MySQL com base no site oficial da Ververica .

1. Dependência

Para configurar o conector CDC do MySQL, a tabela a seguir fornece informações de dependência para dois projetos que usam uma ferramenta de automação de compilação (como Maven ou SBT) e SQL Client com pacote SQL JAR.

1. Dependência Maven

<dependency>
  <groupId>com.alibaba.ververica</groupId>
  <artifactId>flink-connector-mysql-cdc</artifactId>
  <version>1.1.0</version>
</dependency>

2. JAR do cliente SQL

Baixe flink-sql-connector-mysql-cdc-1.1.0.jar e coloque-o em <FLINK_HOME> / lib /.

Dois, configure o servidor MySQL

Você deve definir um usuário MySQL com as permissões apropriadas para todos os bancos de dados monitorados pelo conector Debezium MySQL.

1. Crie um usuário MySQL:

mysql> CREATE USER 'user'@'localhost' IDENTIFIED BY 'password';

2. Conceda as permissões necessárias ao usuário:

mysql> GRANT SELECT, RELOAD, SHOW DATABASES, REPLICATION SLAVE, REPLICATION CLIENT ON *.* TO 'user' IDENTIFIED BY 'password';

3. Finalize as permissões do usuário:

mysql> FLUSH PRIVILEGES;

Veja mais informações sobre as descrições de permissão: https://debezium.io/documentation/reference/1.2/connectors/mysql.html#_permissions_explained .

Três, preste atenção

1. Como funciona o código-fonte do CDC do MySQL?

Ao iniciar a fonte do CDC do MySQL, ele adquirirá um bloqueio de leitura global (FLUSH TABLES WITH READ LOCK), que impedirá a gravação de outros bancos de dados. Em seguida, ele lê a localização atual do log binário e o banco de dados e o esquema da tabela. Depois disso, o bloqueio de leitura global será liberado. Em seguida, ele verifica a tabela do banco de dados e lê o log binário do local registrado anteriormente. O Flink executará periodicamente pontos de verificação para registrar a localização do log bin. Se ocorrer uma falha, o trabalho será reiniciado e recuperado do local do log binário onde o ponto de verificação foi concluído. Portanto, ele garante apenas uma vez semântica.

2. Conceda permissões RELOAD aos usuários MySQL

Se o usuário MySQL não receber permissões RELOAD, a origem do CDC do MySQL usará bloqueios em nível de tabela e usará este método para realizar instantâneos. Isso impedirá a escrita por um longo período de tempo.

3. Bloqueio de leitura global (FLUSH TABLES WITH READ LOCK)

O bloqueio de leitura global é mantido durante a leitura da localização e esquema do log bin. Isso pode demorar alguns segundos , dependendo do número de tabelas. O bloqueio de leitura global evita gravações , portanto, ainda pode afetar os negócios online.
Se você deseja pular o bloqueio de leitura e pode tolerar a semântica pelo menos uma vez , você pode adicionar a opção ** 'debezium.snapshot.locking.mode' = 'none' ** para pular o bloqueio.

4. Defina um SERVER ID diferente para cada trabalho

Cada cliente de banco de dados MySQL usado para ler o log bin deve ter um ID exclusivo chamado id do servidor. O servidor MySQL usará esse ID para manter conexões de rede e locais de log binários. Se diferentes trabalhos compartilham o mesmo ID de servidor, isso pode causar a leitura do local errado do log bin.
Dica: Por padrão, quando o TaskManager é iniciado, o ID do servidor é aleatório. Se o TaskManager falhar, ele pode ter uma ID de servidor diferente quando for iniciado novamente. Mas isso não deve acontecer com frequência (a exceção do job não reiniciará o TaskManager), nem terá muito impacto no servidor MySQL.

Portanto, é recomendado definir um ID de servidor diferente para cada trabalho, por exemplo:

通过Dicas de SQL * : SELECT * FROM source_table / * + OPTIONS ('server-id' = '123456') /;
Definido ao criar a fonte por meio de Stream ApI: ** MySQLSource.builder () .xxxxxx .serverId (123456); **

Importante : pode-se dizer que o binlog do Mysq está no nível da biblioteca, portanto, puxar tabelas diferentes em uma biblioteca ou a mesma tabela com o mesmo ID de servidor pode causar perda de dados. Portanto, é recomendável definir o ID do servidor. (Eu também perguntei ao chefe de Jark no correio da comunidade: endereço de entrega )

5. O ponto de verificação não pode ser executado durante a verificação da tabela do banco de dados

Durante a varredura da mesa, não podemos realizar checkpoints porque não há lugar para se recuperar. Para não realizar um ponto de verificação, a origem do CDC do MySQL manterá o ponto de verificação aguardando o tempo limite. Os pontos de verificação expirados serão identificados como pontos de verificação com falha, o que irá acionar o failover de trabalhos do Flink por padrão. Portanto, se a tabela do banco de dados for grande, é recomendável adicionar a seguinte configuração do Flink para evitar failover devido a pontos de verificação de tempo limite:

execution.checkpointing.interval: 10min
execution.checkpointing.tolerable-failed-checkpoints: 100
restart-strategy: fixed-delay
restart-strategy.fixed-delay.attempts: 2147483647

6. Defina o tempo limite da sessão MySQL

Ao criar um instantâneo inicialmente consistente para um banco de dados grande, a conexão que você estabelece pode expirar durante a leitura da tabela. Você pode evitar esse comportamento configurando Interactive_timeout e wait_timeout no arquivo de configuração do MySQL.

interativo_timeout: O número de segundos que o servidor espera por atividade antes de fechar uma conexão interativa. Consulte a documentação do MySQL .
wait_timeout: O número de segundos que o servidor espera por sua atividade antes de fechar uma conexão não interativa. Consulte a documentação do MySQL .

Quarto, como criar uma tabela CDC do MySQL

1. Método Sql:

(1) A tabela de definição é a seguinte:

-- register a MySQL table 'orders' in Flink SQL
CREATE TABLE orders (
  order_id INT,
  order_date TIMESTAMP(0),
  customer_name STRING,
  price DECIMAL(10, 5),
  product_id INT,
  order_status BOOLEAN
) WITH (
  'connector' = 'mysql-cdc',
  'hostname' = 'localhost',
  'port' = '3306',
  'username' = 'root',
  'password' = '123456',
  'database-name' = 'mydb',
  'table-name' = 'orders'
);

-- read snapshot and binlogs from orders table
SELECT * FROM orders;

(2) Opções de conector

      待补充。。。

2 、 API Stream

O conector CDC do MySQL também pode ser uma fonte DataStream. Você pode criar SourceFunction da seguinte maneira:

import org.apache.flink.streaming.api.environment.StreamExecutionEnvironment;
import org.apache.flink.streaming.api.functions.source.SourceFunction;
import com.alibaba.ververica.cdc.debezium.StringDebeziumDeserializationSchema;
import com.alibaba.ververica.cdc.connectors.mysql.MySQLSource;

public class MySqlBinlogSourceExample {
  public static void main(String[] args) throws Exception {
    SourceFunction<String> sourceFunction = MySQLSource.<String>builder()
      .hostname("localhost")
      .port(3306)
      .databaseList("inventory") // monitor all tables under inventory database
      .username("flinkuser")
      .password("flinkpw")
      .deserializer(new StringDebeziumDeserializationSchema()) // converts SourceRecord to String
      .build();

    StreamExecutionEnvironment env = StreamExecutionEnvironment.getExecutionEnvironment();

    env
      .addSource(sourceFunction)
      .print().setParallelism(1); // use parallelism 1 for sink to keep message ordering

    env.execute();
  }
}

Cinco, características

1. Processamento Exatamente Uma Vez

O conector CDC do MySQL é um conector Flink Source. Ele lerá primeiro o instantâneo do banco de dados e, mesmo se houver uma falha, continuará a ler o log binário com processamento único. Leia como o conector executa instantâneos de banco de dados.

2. Leitura de linha única

A origem do CDC do MySQL não pode ser lida em paralelo porque apenas uma tarefa pode receber eventos Binlog.

6. Mapeamento de tipo de dados.

Para ser adicionado. . .

Sete, perguntas frequentes

1. Como pular o instantâneo e ler apenas do binlog?

Você pode controlar debezium.snapshot.mode por meio de opções , você pode defini-lo para:

nunca: especifica que a conexão nunca deve usar instantâneos e quando o nome do servidor lógico é usado para a primeira inicialização, o conector deve ler desde o início do binlog; use-o com cuidado, porque ele só é válido quando o binlog garantido para conter todo o histórico do banco de dados.
schema_only: se você não precisa de instantâneos contínuos dos dados desde que o conector foi iniciado, mas precisa apenas que eles sejam alterados, você pode usar a opção schema_only, em que o conector tira apenas um instantâneo do esquema (não dos dados).

2. Como ler um banco de dados compartilhado contendo várias tabelas (como user_00, user_01, ..., user_99)?

A opção table-name oferece suporte a expressões regulares para monitorar várias tabelas que correspondem a expressões regulares. Portanto, você pode definir o nome da tabela para o usuário _. * Para monitorar todas as tabelas de prefixo do usuário. A opção do nome do banco de dados é a mesma. Observe que as tabelas compartilhadas devem estar no mesmo esquema.

3. ConnectException: DML '...' recebido para processamento, binlog pode conter instruções de uso ou eventos gerados com base em um formato de cópia mista

Se houver a exceção acima, verifique se o binlog_format é ROW, você pode executá-lo no cliente MySQL executando variáveis show como '% binlog_format%'. Observe que mesmo se a configuração do seu banco de dados para binlog_format for ROW, você pode alterar esta configuração por meio de outras sessões, como SET SESSION binlog_format = 'MIXED'; SET SESSION tx_isolation = 'REPEATABLE-READ'; COMMIT ;. Certifique-se também de que nenhuma outra sessão está alterando esta configuração

8. Problemas encontrados na prática