web-dev-qa-db-fra.com

AWS DMS | ERREUR: impossible d'accéder au fichier "pglogical": aucun fichier ou répertoire de ce type

Erreur -

2019-06-17T05:00:11 [SOURCE_CAPTURE ]E: RetCode: SQL_ERROR SqlState: 58P01 NativeError: 1 Message: ERROR: could not access file "pglogical": No such file or directory;, Error while executing the query [1022502] (ar_odbc_stmt.c:2546)
2019-06-17T05:00:11 [SOURCE_CAPTURE ]E: RetCode: SQL_ERROR SqlState: 42P01 NativeError: 1 Message: ERROR: relation "pglogical.replication_set" does not exist;, No query has been executed with that handle [1022502] (ar_odbc_stmt.c:3722)

Nous recevons cette erreur tous les 3 mois environ. Le redémarrage de la tâche résout le problème mais la reprise ne fonctionne pas.

L'emplacement de réplication existe mais semble être inactif -

   postgres=> select * from pg_replication_slots ;
                               slot_name                            |    plugin     | slot_type | datoid |   database    | active | active_pid | xmin | catalog_xmin | restart_lsn
    ----------------------------------------------------------------+---------------+-----------+--------+---------------+--------+------------+------+--------------+--------------
     juvmrynv47ajpwrc_00016389_f28d6802_db75_43d6_8058_315783e9b1b2 | test_decoding | logical   |  16389 | postgres | f      |            |      |    148271120 | 8DF/B292FB48
    (1 row)
9
vivekyad4v

Dans notre cas, les transactions actives étaient à l'origine de cet échec. Ainsi, alors que la tâche DMS est reprise après un échec ou manuellement, elle essaiera de créer un emplacement de réplication factice qui ne nécessite aucune transaction active sur la base de données source, par défaut DMS attendra 10 minutes pour que les transactions actives se terminent, puis la tâche échouera avec ci-dessous Erreur.

2019-09-02T06:48:10 [SOURCE_CAPTURE  ]E:  RetCode: SQL_ERROR  SqlState: 57014 NativeError: 1 Message: ERROR: canceling statement due to statement timeout;
Error while executing the query [1022502]  (ar_odbc_stmt.c:2581)

Solution -

  • Augmentez les paramètres de tâche TransactionConsistencyTimeout de 600 secondes à 1800 secondes.
  • Vérifiez si votre instance de réplication consomme trop de mémoire.
  • Activez le mode débogage dans vos paramètres de tâche et obtenez plus de détails sur l'échec -

    "LogComponents": [
      {
        "Id": "SOURCE_UNLOAD",
        "Severity": "LOGGER_SEVERITY_DETAILED_DEBUG"
      },
      {
        "Id": "SOURCE_CAPTURE",
        "Severity": "LOGGER_SEVERITY_DETAILED_DEBUG"
      },
      {
        "Id": "TARGET_LOAD",
        "Severity": "LOGGER_SEVERITY_DETAILED_DEBUG"
      },
      {
        "Id": "TARGET_APPLY",
        "Severity": "LOGGER_SEVERITY_DETAILED_DEBUG"
      },
      {
        "Id": "TASK_MANAGER",
        "Severity": "LOGGER_SEVERITY_DETAILED_DEBUG"
      }
    ]
    
2
vivekyad4v

Je fais face à la même erreur que OP décrit. Pour moi, l'environnement que j'exécute est: - Utilisation de DMS version 3.1.4 - Utilisation de la cible et de la source comme Postgresql Aurora 10.7

Plus tard, tout en vérifiant le document sur la configuration de celui-ci sur https://docs.aws.Amazon.com/dms/latest/userguide/CHAP_Source.PostgreSQL.html , a découvert qu'en fait pour la version Postgres > 10, je dois utiliser les versions DMS 3.3.0 et suivantes.

Modifiez la version pour la faire fonctionner, alors assurez-vous de vérifier le document d'Amazon avant de venir ici :)

1