Tous les produits
Search
Centre de documentation

ApsaraDB RDS:Obtenir et analyser à distance le fichier journal binaire d'une instance ApsaraDB RDS for MySQL

Dernière mise à jour :Aug 08, 2026

Utilisez mysqlbinlog pour télécharger les fichiers journaux binaires depuis une instance ApsaraDB RDS for MySQL et en analyser le contenu afin de déboguer, auditer ou récupérer des données.

Prérequis

Avant de commencer, assurez-vous de disposer des éléments suivants :

  • Une instance ApsaraDB RDS for MySQL avec la fonctionnalité de sauvegarde des journaux activée. Pour l'activer, consultez la section Procédure

  • Un client MySQL installé localement, exécutant la même version de MySQL que l'instance RDS

  • L'endpoint de l'instance. Pour le trouver, consultez la page Afficher et gérer les endpoints et ports des instances

  • Un compte de base de données disposant des permissions suffisantes pour se connecter à l'instance

Télécharger les fichiers journaux binaires

Deux méthodes sont disponibles. Privilégiez la méthode via la console, sauf si vous avez besoin d'un accès programmatique ou en temps réel.

Méthode 1 (recommandée) : Téléchargement depuis la console

  • Instances sur disque cloud : la sauvegarde des journaux est activée par défaut. Les journaux binaires sont chargés en temps réel dans le stockage de sauvegarde. Vous pouvez télécharger les journaux à tout moment depuis la console. Consultez la section relative aux disques cloud dans les Méthodes de téléchargement.

  • Instances sur disque local : consultez la section relative aux disques locaux dans les Méthodes de téléchargement.

Méthode 2 : Téléchargement avec mysqlbinlog

Cette méthode permet de télécharger directement les fichiers journaux binaires sur votre machine à l'aide de mysqlbinlog.

  1. Connectez-vous à l'instance RDS :

    mysql -u<username> -p -h<endpoint>
  2. Répertoriez les fichiers journaux binaires disponibles et notez les valeurs Log_name :

    SHOW BINARY LOGS;

    Le résultat liste les fichiers journaux binaires disponibles :

    mysql> SHOW BINARY LOGS;
    +------------------+-----------+
    | Log_name         | File_size |
    +------------------+-----------+
    | mysql-bin.000022 |    406039 |
    | mysql-bin.000023 |     71497 |
    +------------------+-----------+
    2 rows in set (0.01 sec)
  3. Quittez l'interface CLI MySQL :

    exit;
  4. Téléchargez le fichier journal binaire sur votre machine locale. Remplacez <mysql-bin.XXX> par le nom du fichier obtenu à l'étape 2 et <output-file> par le nom du fichier local de destination :

    • --read-from-remote-server — se connecte au serveur MySQL distant pour diffuser le contenu du journal binaire.

    • --raw — enregistre le fichier au format binaire brut plutôt qu'en texte.

    • -u<username> — nom d'utilisateur du compte de base de données.

    • -p<password> — mot de passe du compte de base de données.

    • -h<endpoint> — endpoint de l'instance RDS.

    • <mysql-bin.XXX> — nom du fichier journal binaire obtenu à l'étape 2.

    • > <output-file> — fichier local dans lequel enregistrer le journal binaire.

    mysqlbinlog \
      -u<username> \
      -p<password> \
      -h<endpoint> \
      --read-from-remote-server \
      --raw \
      <mysql-bin.XXX> > <output-file>

    Paramètres :

  5. Vérifiez que le fichier a bien été téléchargé :

    more <output-file>

Analyser les fichiers journaux binaires

Après avoir téléchargé le fichier journal binaire, utilisez mysqlbinlog pour analyser et afficher son contenu.

Pour afficher la sortie analysée page par page :

mysqlbinlog \
  -vv \
  --base64-output=decode-rows \
  <mysql-bin.XXX> | more

Pour écrire la sortie analysée dans un fichier :

mysqlbinlog \
  -vv \
  --base64-output=decode-rows \
  <mysql-bin.XXX> > <output-file>

Paramètres :

  • -vv — affiche des informations détaillées sur les événements, y compris les modifications au niveau des lignes sous forme lisible.

  • --base64-output=decode-rows — décode les événements de ligne encodés en Base64 afin que vous puissiez lire les instructions SQL.

  • <mysql-bin.XXX> — fichier journal binaire à analyser.

  • | more — parcourt la sortie écran par écran.

  • > <output-file> — écrit la sortie dans un fichier local.

La sortie analysée ressemble à ce qui suit :

[root@iZbp****** ~]# mysqlbinlog -vv --base64-output=decode-rows mysql-bin.000022 | more
# The proper term is pseudo_replica_mode, but we use this compatibility alias
# to make the statement usable on server versions 8.0.24 and older.
/*!50530 SET @@SESSION.PSEUDO_SLAVE_MODE=1*/;
/*!50003 SET @OLD_COMPLETION_TYPE=@@COMPLETION_TYPE,COMPLETION_TYPE=0*/;
DELIMITER /*!*/;
# at 4
#230911  9:27:28 server id 26718053  end_log_pos 123 CRC32 0xa231cb44   Start: binlog v 4, server v 5.7.42-log created 230911  9:27:28
# at 123
#230911  9:27:28 server id 26718053  end_log_pos 194 CRC32 0x078b6dc1   Previous-GTIDs
# a63b4ed1-4c86-11ee-9029-00163e157053:1-27339
# at 194
#230911  9:27:32 server id 26718053  end_log_pos 259 CRC32 0x59b848c3   GTID    last_committed=0        sequence_number=1       rbr_only=yes    original_committed_ti
mestamp=0       immediate_commit_timestamp=0    transaction_length=0
/*!50718 SET TRANSACTION ISOLATION LEVEL READ COMMITTED*//*!*/;
# original_commit_timestamp=0 (1970-01-01 08:00:00.000000 CST)
# immediate_commit_timestamp=0 (1970-01-01 08:00:00.000000 CST)
/*!80001 SET @@session.original_commit_timestamp=0*//*!*/;
/*!80014 SET @@session.original_server_version=0*//*!*/;
/*!80014 SET @@session.immediate_server_version=0*//*!*/;
SET @@SESSION.GTID_NEXT= 'a63b4ed1-4c86-11ee-9029-00163e157053:27340'/*!*/;
# at 259
#230911  9:27:32 server id 26718053  end_log_pos 327 CRC32 0xc0dddaec   Query   thread_id=16849 exec_time=0     error_code=0
SET TIMESTAMP=1694395652/*!*/;
SET @@session.pseudo_thread_id=16849/*!*/;
SET @@session.foreign_key_checks=1, @@session.sql_auto_is_null=0, @@session.unique_checks=1, @@session.autocommit=1/*!*/;
SET @@session.sql_mode=2097152/*!*/;
SET @@session.auto_increment_increment=1, @@session.auto_increment_offset=1/*!*/;
/*!\C utf8mb3 *//*!*/;
SET @@session.character_set_client=33,@@session.collation_connection=33,@@session.collation_server=33/*!*/;
SET @@session.lc_time_names=0/*!*/;
SET @@session.collation_database=DEFAULT/*!*/;
BEGIN

Pour plus de détails sur les options de mysqlbinlog , consultez la documentation MySQL .

FAQ

La sortie affiche du contenu binaire illisible au lieu d'instructions SQL.

Ajoutez l'option --base64-output=decode-rows à la commande mysqlbinlog . Sans cette option, les événements de journal binaire basés sur les lignes s'affichent au format brut encodé en Base64.

image.png

J'obtiens l'erreur suivante : ERROR: Error in Log_event::read_log_event(): 'Sanity check failed'

ERROR: Error in Log_event::read_log_event(): 'Sanity check failed', data_len: 151, event_type: 35
ERROR: Could not read entry at offset 120: Error in log format or read error.

Il s'agit d'un problème connu dans mysqlbinlog 3.3. Mettez à niveau vers mysqlbinlog 3.4 ou une version ultérieure pour le résoudre.

J'obtiens l'erreur suivante : mysqlbinlog: [ERROR] unknown variable 'default-character-set=utf8mb4'

Votre fichier de configuration my.cnf contient l'option default-character-set=utf8mb4, qui n'est pas prise en charge par mysqlbinlog. Ajoutez l'option --no-defaults pour ignorer le fichier de configuration :

mysqlbinlog \
  --no-defaults \
  -u<username> \
  -p<password> \
  -h<endpoint> \
  --read-from-remote-server \
  <mysql-bin.XXX> > <output-file>

Les horodatages de la sortie analysée ne correspondent pas aux heures réelles des événements.

Les horodatages des journaux binaires sont stockés sous forme d'horodatages UNIX sans information de fuseau horaire. mysqlbinlog les convertit en utilisant le fuseau horaire local de la machine sur laquelle vous exécutez la commande. Si ce fuseau horaire diffère de celui de l'instance RDS, les heures affichées seront incorrectes. Définissez votre fuseau horaire local pour qu'il corresponde à celui de l'instance RDS avant d'exécuter mysqlbinlog .

Périmètre d'application

ApsaraDB RDS for MySQL