Tous les produits
Search
Centre de documentation

Hologres:Consume Binlog via JDBC

Dernière mise à jour :Aug 11, 2026

Le journal binaire (Binlog) de Hologres suit les opérations INSERT, UPDATE, DELETE et TRUNCATE sous la forme d'un flux d'événements de modification. Cette rubrique explique comment consommer ce flux en utilisant directement Java Database Connectivity (JDBC) ou via Holo-Client, le SDK Java de Hologres.

Prérequis

Avant de commencer, vérifiez que vous disposez des éléments suivants :

  • La fonctionnalité Binlog est activée sur la table cible. Consultez la rubrique S'abonner aux données Binlog de Hologres.

  • L'extension hg_binlog est créée (uniquement pour Hologres V1.x). À partir de la version 2.0, l'extension est intégrée ; aucune configuration manuelle n'est requise. Pour les versions de Hologres antérieures à la V2.0, un superutilisateur doit exécuter l'instruction suivante une fois par base de données. Si vous créez une nouvelle base de données, exécutez-la à nouveau.

    Important

    N'utilisez jamais DROP EXTENSION <extension_name> CASCADE. L'option CASCADE supprime toutes les données de l'extension, y compris les données PostGIS, RoaringBitmap, Proxima, Binlog et BSI, et supprime tous les objets dépendants tels que les tables, les vues, les métadonnées et les données du serveur.

    -- Create the extension.
    CREATE EXTENSION hg_binlog;
    
    -- Remove the extension.
    DROP EXTENSION hg_binlog;
  • Configuration de l'accès en fonction de votre version de Hologres : pour créer une publication et un emplacement de réplication (requis pour toutes les versions utilisant cette méthode), l'utilisateur doit disposer de l'un des ensembles d'autorisations suivants :

    • Autorisations de superutilisateur sur l'instance

    • Autorisations de propriétaire sur la table cible, autorisations CREATE DATABASE et rôle de réplication sur l'instance

    Remarque

    À partir de la version 2.0, le mode Holohub n'est plus pris en charge. Avant de passer à la version 2.0 ou ultérieure, mettez d'abord à jour Flink vers la version 8.0.5. Après la mise à niveau, le mode JDBC est utilisé automatiquement.

    Version de Hologres Version du moteur Flink Prérequis
    V2.1 et ultérieure 8.0.5 et ultérieure Autorisations de lecture sur la table cible. Aucun emplacement de réplication n'est nécessaire.
    V2.0 8.0.5 et antérieure Une publication et un emplacement de réplication. Consultez la section Créer une publication et un emplacement de réplication.
    V1.3 et antérieure 8.0.5 et antérieure Autorisations de lecture sur la table cible. Le mode Holohub est utilisé automatiquement.

Limites

  • La consommation du journal binaire (Binlog) via JDBC nécessite Hologres V1.1 ou ultérieure.

  • Types de données de colonne pris en charge : INTEGER, BIGINT, SMALLINT, TEXT, CHAR(n), VARCHAR(n), REAL, DOUBLE PRECISION, BOOLEAN, NUMERIC(38,8), DATE, TIME, TIMETZ, TIMESTAMP, TIMESTAMPTZ, BYTEA, JSON, SERIAL, OID, int4[], int8[], float4[], float8[], boolean[] et text[]. Si une table contient des colonnes de types non pris en charge, la consommation échoue. À partir de la version 1.3.36, les colonnes JSONB sont également prises en charge. Activez le paramètre Grand Unified Configuration (GUC) suivant avant la consommation :

    -- Enable at the session level.
    SET hg_experimental_enable_binlog_jsonb = ON;
    
    -- Enable at the database level.
    ALTER DATABASE <db_name> SET hg_experimental_enable_binlog_jsonb = ON;
  • Chaque shard de chaque table consommée utilise une connexion Walsender. Les connexions Walsender sont indépendantes des connexions régulières.

  • Le nombre maximal de Walsenders par nœud frontal varie selon la version. Pour vérifier la limite actuelle, procédez comme suit :

    1. Identifiez les travaux de consommation Binlog JDBC actifs et arrêtez ceux qui ne sont pas nécessaires.

    2. Vérifiez si les paramètres du groupe de tables et du nombre de shards sont appropriés. Consultez la rubrique Bonnes pratiques pour la définition des groupes de tables.

    3. Si la limite est toujours dépassée, augmentez la capacité de l'instance (scale out).

    Version Nombre maximal de Walsenders par nœud frontal
    V2.2 et ultérieure 600
    V2.0 et V2.1 1 000
    V1.1.26 à V2.0 100
    SHOW max_wal_senders;

    Valeurs par défaut : la limite totale est max_wal_senders × number of frontend nodes. Pour connaître le nombre de nœuds frontaux correspondant à une spécification d'instance donnée, consultez la rubrique Gestion des instances. Utilisez cette formule pour estimer le nombre de tables que vous pouvez consommer simultanément :

    Number of tables ≤ (max_wal_senders × number of frontend nodes) / table shard count

    Exemple : une instance avec deux nœuds frontaux exécutant la version 2.2 dispose d'un total de 600 × 2 = 1 200 Walsenders. Pour des tables avec un nombre de shards de 20, elle peut prendre en charge jusqu'à 60 consommations de tables simultanées. Si deux travaux consomment la même table simultanément, chacun utilise 20 Walsenders, soit un total de 40. Si la limite de Walsenders est atteinte, le message suivant s'affiche :

    FATAL: sorry, too many wal senders already

    Pour résoudre ce problème :

  • Instances secondaires en lecture seule : la consommation Binlog via JDBC n'est pas prise en charge avant la version 2.0.18. À partir de la version 2.0.18, les instances secondaires prennent en charge la consommation Binlog mais n'enregistrent pas la progression de la consommation.

Créer une publication et un emplacement de réplication

Requis pour Hologres V2.0 et versions antérieures. À partir de la version 2.1, les utilisateurs disposant uniquement des autorisations de lecture sur la table cible peuvent consommer les données Binlog sans emplacement de réplication ; ignorez cette section si vous utilisez la version 2.1 ou ultérieure.

Publication

Une publication définit les modifications de quelle table sont mises à disposition pour la réplication logique. Dans Hologres, une publication est liée à exactement une table physique, et cette table doit avoir le Binlog activé.

Créer une publication

CREATE PUBLICATION <name> FOR TABLE <table_name>;
Paramètre Description
name Nom personnalisé pour la publication.
table_name Nom de la table cible.

Exemple :

CREATE PUBLICATION hg_publication_test_1 FOR TABLE test_message_src;

Interroger les publications

SELECT * FROM pg_publication;

Exemple de sortie :

         pubname        | pubowner | puballtables | pubinsert | pubupdate | pubdelete | pubtruncate
------------------------+----------+--------------+-----------+-----------+-----------+-------------
 hg_publication_test_1  |    16728 | f            | t         | t         | t         | t
(1 row)
Champ Description
pubname Nom de la publication.
pubowner Propriétaire de la publication.
puballtables Indique si toutes les tables sont incluses. Toujours false : la liaison de plusieurs tables physiques n'est pas prise en charge.
pubinsert Indique si les événements INSERT sont publiés. Par défaut : true.
pubupdate Indique si les événements UPDATE sont publiés. Par défaut : true.
pubdelete Indique si les événements DELETE sont publiés. Par défaut : true.
pubtruncate Indique si les événements TRUNCATE sont publiés. Par défaut : true.

Pour plus d'informations sur les types d'événements Binlog, consultez la rubrique Format et principes du Binlog.

Interroger les tables d'une publication

SELECT * FROM pg_publication_tables;

Exemple de sortie :

         pubname        | schemaname |    tablename
------------------------+------------+------------------
 hg_publication_test_1  | public     | test_message_src
(1 row)

Supprimer une publication

DROP PUBLICATION <name>;

Exemple :

DROP PUBLICATION hg_publication_test_1;

Emplacement de réplication

Important

Un emplacement de réplication inactif continue de conserver les données WAL sur le serveur. Si un emplacement n'est pas consommé, les données WAL s'accumulent et peuvent épuiser votre stockage. Supprimez tout emplacement dont vous n'avez plus besoin.

Un emplacement de réplication suit la progression de la consommation d'une publication et permet une transmission reprenable. Après un basculement, un consommateur peut reprendre à partir du dernier point de contrôle validé enregistré dans l'emplacement.

Seuls les superutilisateurs et les utilisateurs disposant du rôle de réplication peuvent créer et utiliser des emplacements de réplication. Pour accorder ou révoquer le rôle de réplication :

-- Grant the Replication Role to a user.
ALTER ROLE <user_name> REPLICATION;

-- Revoke the Replication Role from a user.
ALTER ROLE <user_name> NOREPLICATION;

user_name est un ID de compte Alibaba Cloud ou un utilisateur Resource Access Management (RAM). Consultez la rubrique Aperçu des comptes.

Créer un emplacement de réplication

CALL hg_create_logical_replication_slot('<replication_slot_name>', 'hgoutput', '<publication_name>');
Paramètre Description
replication_slot_name Nom personnalisé pour l'emplacement de réplication.
hgoutput Plugin de sortie pour le format Binlog. Seul hgoutput est pris en charge.
publication_name Nom de la publication à lier.

Exemple :

CALL hg_create_logical_replication_slot('hg_replication_slot_1', 'hgoutput', 'hg_publication_test_1');

Interroger les emplacements de réplication

SELECT * FROM hologres.hg_replication_slot_properties;

Exemple de sortie :

        slot_name       | property_key |      property_value
------------------------+--------------+------------------------
 hg_replication_slot_1  | plugin       | hgoutput
 hg_replication_slot_1  | publication  | hg_publication_test_1
 hg_replication_slot_1  | parallelism  | 1
(3 rows)
Champ Description
slot_name Nom de l'emplacement de réplication.
property_key L'une des valeurs suivantes : plugin (plugin de sortie), publication (publication liée) ou parallelism (nombre de connexions simultanées requises pour consommer la table entière, égal au nombre de shards du groupe de tables).
property_value Valeur de la propriété correspondante.

Interroger le parallélisme requis

Étant donné que Hologres est une base de données distribuée, les données de chaque table sont réparties sur plusieurs shards. Vous avez besoin d'une connexion par shard pour consommer la table entière. Pour vérifier le nombre de connexions simultanées requises par hg_replication_slot_1 :

SELECT hg_get_logical_replication_slot_parallelism('hg_replication_slot_1');

Exemple de sortie :

 hg_get_logical_replication_slot_parallelism
---------------------------------------------
                                          20

Interroger la progression de la consommation

La table hologres.hg_replication_progress enregistre le décalage du consommateur que vous validez explicitement.

SELECT * FROM hologres.hg_replication_progress;

Exemple de sortie :

        slot_name       | parallel_index | lsn
------------------------+----------------+-----
 hg_replication_slot_1  |              0 |  66
 hg_replication_slot_1  |              1 | 122
 hg_replication_slot_1  |              2 | 119
(3 rows)
Champ Description
slot_name Nom de l'emplacement de réplication.
parallel_index Index de la connexion simultanée (un par shard).
lsn Numéro de séquence de journal (LSN) du dernier enregistrement Binlog consommé qui a été validé.
Important
  • La table hologres.hg_replication_progress est créée uniquement après la première consommation Binlog.

  • La table enregistre uniquement les décalages que vous validez explicitement en appelant la fonction de validation LSN dans votre code. La valeur enregistrée peut ne pas correspondre à la position réelle du consommateur. Suivez le LSN côté client et utilisez-le comme point de récupération.

  • Les validations de points de contrôle sont effectives uniquement lors de la consommation via un emplacement de réplication. Lors de la consommation par nom de table uniquement (sans withSlotName), la progression n'est pas enregistrée.

Supprimer un emplacement de réplication

Supprimez un emplacement lorsque vous n'en avez plus besoin pour éviter l'accumulation de données WAL. Les emplacements ne se ferment pas automatiquement lorsqu'un travail de consommation s'arrête ; vous devez les supprimer manuellement.

CALL hg_drop_logical_replication_slot('<replication_slot_name>');

Exemple :

CALL hg_drop_logical_replication_slot('hg_replication_slot_1');

Consommer les données Binlog via JDBC

La consommation basée sur JDBC vous offre un contrôle précis sur chaque shard. Vous créez un PGReplicationStream par shard et gérez vous-même le parallélisme.

Étape 1 : Ajouter les dépendances

Utilisez JDBC 42.2.18 ou ultérieur. Ajoutez les dépendances suivantes à votre fichier pom.xml :

<dependency>
    <groupId>org.postgresql</groupId>
    <artifactId>postgresql</artifactId>
    <version>42.3.8</version>
</dependency>
<!-- Used to get the table schema and decode Binlog records -->
<dependency>
    <groupId>com.alibaba.hologres</groupId>
    <artifactId>holo-client</artifactId>
    <version>2.2.10</version>
</dependency>

Étape 2 : Se connecter et consommer

L'exemple suivant se connecte à un emplacement de réplication, lit les enregistrements Binlog d'un shard et affiche chaque enregistrement.

import com.alibaba.hologres.client.HoloClient;
import com.alibaba.hologres.client.HoloConfig;
import com.alibaba.hologres.client.impl.binlog.HoloBinlogDecoder;
import com.alibaba.hologres.client.model.Record;
import com.alibaba.hologres.client.model.TableSchema;

import org.postgresql.PGConnection;
import org.postgresql.PGProperty;
import org.postgresql.replication.LogSequenceNumber;
import org.postgresql.replication.PGReplicationStream;

import java.nio.ByteBuffer;
import java.sql.Connection;
import java.sql.DriverManager;
import java.util.Arrays;
import java.util.List;
import java.util.Properties;

public class Test {

    public static void main(String[] args) throws Exception {

        String username = "";
        String password = "";
        String url = "jdbc:postgresql://Endpoint:Port/db_test";

        // Set up the JDBC connection for replication.
        Properties properties = new Properties();
        PGProperty.USER.set(properties, username);
        PGProperty.PASSWORD.set(properties, password);
        PGProperty.ASSUME_MIN_SERVER_VERSION.set(properties, "9.4");
        // Required for Binlog consumption.
        PGProperty.REPLICATION.set(properties, "database");

        try (Connection connection = DriverManager.getConnection(url, properties)) {

            // Each PGReplicationStream consumes one shard. Set shardId for each stream.
            int shardId = 0;
            PGConnection pgConnection = connection.unwrap(PGConnection.class);
            PGReplicationStream pgReplicationStream = pgConnection.getReplicationAPI()
                    .replicationStream()
                    .logical()
                    // V2.1+: two options
                    // Option 1: specify the replication slot name. table_name is ignored.
                    // Option 2: omit withSlotName and set table_name in withSlotOption instead.
                    .withSlotName("slot_name")
                    .withSlotOption("table_name", "public.test_message_src")
                    .withSlotOption("parallel_index", shardId)
                    .withSlotOption("batch_size", "1024")
                    .withSlotOption("start_time", "2021-01-01 00:00:00")
                    .withSlotOption("start_lsn", "0")
                    .start();

            // HoloClient is needed to get the table schema for decoding.
            HoloConfig holoConfig = new HoloConfig();
            holoConfig.setJdbcUrl(url);
            holoConfig.setUsername(username);
            holoConfig.setPassword(password);
            HoloClient client = new HoloClient(holoConfig);

            // Decode raw binary Binlog data into BinlogRecord objects.
            TableSchema schema = client.getTableSchema("test_message_src", true);
            HoloBinlogDecoder decoder = new HoloBinlogDecoder(schema);

            // Track the last consumed LSN for checkpoint recovery.
            Long currentLsn = 0L;

            ByteBuffer byteBuffer = pgReplicationStream.readPending();
            while (true) {
                if (byteBuffer != null) {
                    List<BinlogRecord> records = decoder.decode(shardId, byteBuffer);
                    Long latestLsn = 0L;
                    for (BinlogRecord record : records) {
                        latestLsn = record.getBinlogLsn();
                        // Process the record here.
                        System.out.println("lsn: " + latestLsn + ", record: " + Arrays.toString(record.getValues()));
                    }
                    // Save the latest LSN as the recovery point.
                    currentLsn = latestLsn;
                    pgReplicationStream.forceUpdateStatus();
                }
                byteBuffer = pgReplicationStream.readPending();
            }
        }
    }
}

Paramètres

Comportement de withSlotName selon la version :

Version Comportement
Antérieure à V2.1 Spécifiez le nom d'un emplacement de réplication existant. Requis.
V2.1 et ultérieure Facultatif. Omettez withSlotName et définissez table_name dans withSlotOption pour consommer sans emplacement de réplication.

Paramètres withSlotOption :

Paramètre Requis Description
table_name Requis lorsque withSlotName n'est pas défini Table cible à consommer. Format : schema_name.table_name ou table_name. Ignoré si withSlotName est défini.
parallel_index Oui Index du shard à consommer. Un PGReplicationStream gère un shard. Pour une table avec trois shards, créez trois flux avec parallel_index 0, 1 et 2.
start_time Non Commencer la consommation à partir de cet horodatage. Exemple : 2021-01-01 12:00:00+08.
start_lsn Non Commencer la consommation à partir de l'enregistrement suivant ce LSN. Prioritaire sur start_time.
batch_size Non Nombre maximal d'enregistrements par récupération. Par défaut : 1 024.

Comportement de démarrage par défaut (lorsque ni start_lsn ni start_time n'est défini) :

Scénario Comportement
Première consommation depuis un emplacement de réplication Démarre depuis le début, similaire au décalage le plus ancien de Kafka.
Consommation ultérieure depuis un emplacement de réplication Reprend à partir du dernier point de contrôle validé.
Consommation par nom de table uniquement (sans withSlotName) Démarre toujours depuis le début.

Champs BinlogRecord

BinlogRecord expose les champs système Binlog suivants :

Méthode Retourne
getBinlogLsn() Le LSN de l'enregistrement Binlog.
getBinlogTimestamp() L'horodatage système au moment de l'événement.
getBinlogEventType() Le type d'événement : INSERT, UPDATE, DELETE ou TRUNCATE.

Pour une référence complète des champs, consultez la rubrique S'abonner aux données Binlog de Hologres.

Valider le point de contrôle

Après avoir consommé les données Binlog, validez le point de contrôle en appelant la fonction de validation LSN. Cela sert deux objectifs : informer le serveur des segments WAL qu'il peut archiver ou supprimer en toute sécurité, et fournir un point de récupération afin que la consommation puisse reprendre à la position correcte après un basculement.

L'exemple de code ci-dessus n'inclut pas cette étape ; ajoutez-la en fonction des exigences de récupération de votre application.

Consommer les données Binlog via Holo-Client

Holo-Client simplifie la consommation Binlog en gérant automatiquement les connexions au niveau des shards. Spécifiez la table cible et Holo-Client s'occupe du reste.

  • Le nombre de connexions est égal au nombre de shards de la table.

  • Enregistrez le point de contrôle par shard afin que la consommation puisse reprendre à la position correcte après une panne réseau ou toute autre interruption.

Remarque

Utilisez Holo-Client 2.2.10 ou ultérieur. Les versions 2.2.9 et antérieures présentent une fuite de mémoire.

Étape 1 : Ajouter les dépendances

<dependency>
    <groupId>com.alibaba.hologres</groupId>
    <artifactId>holo-client</artifactId>
    <version>2.2.10</version>
</dependency>

Étape 2 : Se connecter et consommer

L'exemple suivant s'abonne à une table, traite chaque enregistrement, enregistre un point de contrôle par shard et effectue des tentatives en cas d'échec.

import com.alibaba.hologres.client.BinlogShardGroupReader;
import com.alibaba.hologres.client.Command;
import com.alibaba.hologres.client.HoloClient;
import com.alibaba.hologres.client.HoloConfig;
import com.alibaba.hologres.client.Subscribe;
import com.alibaba.hologres.client.exception.HoloClientException;
import com.alibaba.hologres.client.impl.binlog.BinlogOffset;
import com.alibaba.hologres.client.model.binlog.BinlogHeartBeatRecord;
import com.alibaba.hologres.client.model.binlog.BinlogRecord;

import java.util.HashMap;
import java.util.Map;

public class HoloBinlogExample {

    public static BinlogShardGroupReader reader;

    public static void main(String[] args) throws Exception {
        String username = "";
        String password = "";
        String url = "jdbc:postgresql://ip:port/database";
        String tableName = "test_message_src";
        String slotName = "hg_replication_slot_1";

        HoloConfig holoConfig = new HoloConfig();
        holoConfig.setJdbcUrl(url);
        holoConfig.setUsername(username);
        holoConfig.setPassword(password);
        holoConfig.setBinlogReadBatchSize(128);
        holoConfig.setBinlogIgnoreDelete(true);
        holoConfig.setBinlogIgnoreBeforeUpdate(true);
        holoConfig.setBinlogHeartBeatIntervalMs(5000L);
        HoloClient client = new HoloClient(holoConfig);

        // Get the shard count to initialize per-shard checkpoint tracking.
        int shardCount = Command.getShardCount(client, client.getTableSchema(tableName));

        // Initialize the checkpoint map with LSN 0 for each shard.
        Map<Integer, Long> shardIdToLsn = new HashMap<>(shardCount);
        for (int i = 0; i < shardCount; i++) {
            shardIdToLsn.put(i, 0L);
        }

        // Before V2.1: tableName and slotName are both required.
        // V2.1 and later: tableName is enough (slotName defaults to "hg_table_name_slot").
        Subscribe subscribe = Subscribe.newStartTimeBuilder(tableName, slotName)
                .setBinlogReadStartTime("2021-01-01 12:00:00")
                .build();

        reader = client.binlogSubscribe(subscribe);

        BinlogRecord record;
        int retryCount = 0;

        while (true) {
            try {
                if (reader.isCanceled()) {
                    // Re-create the reader using the last saved checkpoint.
                    reader = client.binlogSubscribe(subscribe);
                }
                while ((record = reader.getBinlogRecord()) != null) {
                    if (record instanceof BinlogHeartBeatRecord) {
                        // All data up to this heartbeat's timestamp has been consumed on this shard.
                        continue;
                    }

                    // Process the record here.
                    System.out.println(record);

                    // Save the checkpoint so consumption can resume from here on failure.
                    shardIdToLsn.put(record.getShardId(), record.getBinlogLsn());
                    retryCount = 0;
                }
            } catch (HoloClientException e) {
                if (++retryCount > 10) {
                    throw new RuntimeException(e);
                }
                System.out.println(String.format(
                        "Binlog read failed: %s. Retrying (%d/10)...", e.getMessage(), retryCount));

                // Wait before retrying, with increasing backoff.
                Thread.sleep(5000L * retryCount);

                // Resume from the saved per-shard checkpoint.
                Subscribe.OffsetBuilder subscribeBuilder = Subscribe.newOffsetBuilder(tableName, slotName);
                for (int i = 0; i < shardCount; i++) {
                    subscribeBuilder.addShardStartOffset(i,
                            new BinlogOffset().setSequence(shardIdToLsn.get(i)));
                }
                subscribe = subscribeBuilder.build();
                reader.cancel();
            }
        }
    }
}

Paramètres

Types Subscribe :

Type Cas d'utilisation
Subscribe.newStartTimeBuilder(tableName, slotName) Démarrer la consommation à partir d'un horodatage spécifique.
Subscribe.newOffsetBuilder(tableName, slotName) Démarrer la consommation à partir d'un LSN spécifique par shard ; utilisez cette option pour la récupération basée sur les points de contrôle.

Note sur la version : avant la version 2.1, tableName et slotName sont tous deux requis. À partir de la version 2.1, seul tableName est requis (équivalent à l'utilisation du nom d'emplacement fixe hg_table_name_slot).

Paramètres Binlog HoloConfig :

Paramètre Par défaut Description
binlogReadBatchSize 1 024 Nombre maximal d'enregistrements par récupération par shard.
binlogHeartBeatIntervalMs -1 (désactivé) Intervalle en millisecondes entre les messages BinlogHeartBeatRecord. Lorsqu'aucune nouvelle donnée n'arrive, les enregistrements de pulsation indiquent que toutes les données jusqu'à cet horodatage ont été consommées sur ce shard.
binlogIgnoreDelete false Ignorer les événements DELETE.
binlogIgnoreBeforeUpdate false Ignorer les enregistrements d'image avant (before-image) pour les événements UPDATE.

Dépannage

La table hologres.hg_replication_progress est manquante ou vide

Si la table n'existe pas ou n'affiche aucune donnée après la validation de la progression de la consommation, vérifiez les points suivants :

Consommation par nom de table sans emplacement de réplication. Si vous n'avez pas défini withSlotName (JDBC) ou n'avez pas spécifié d'emplacement (Holo-Client), le suivi de la progression n'est pas pris en charge. La table ne sera ni créée ni mise à jour. Passez à la consommation basée sur un emplacement de réplication pour activer le suivi de la progression.

Première consommation sur une instance secondaire en lecture seule. Sur les instances secondaires exécutant une version de Hologres antérieure à la 2.0.18, la table hologres.hg_replication_progress ne peut pas être créée lors de la première consommation Binlog. Effectuez une consommation depuis l'instance principale une fois, puis revenez à l'instance secondaire.

Si aucun de ces cas ne s'applique, contactez le support via le groupe DingTalk Hologres. Consultez la rubrique Comment obtenir davantage de support en ligne ?.

Étapes suivantes