Options d'exécution avancées

Outre les options d'exécution, d'arrêt et de reprise standards, plusieurs autres options d'exécution des tâches sont disponibles. Vous pouvez ouvrir la boîte de dialogue Options d'exécution avancées via l'une des méthodes suivantes :

Sélectionnez Options d'exécution avancées dans le menu de la tâche de réplication, dans une vue Pipeline ou Mosaïque.
Ouvrez la tâche de réplication et sélectionnez Options d'exécution avancées dans le menu dans le coin supérieur droit.

Traitement des modifications

Dans la boîte de dialogue Options d'exécution avancées, sélectionnez Traiter les modifications. Les options suivantes sont disponibles :

Les tables sont déjà chargées. Démarrez le traitement des modifications depuis :

Note InformationsLes modifications des métadonnées effectuées dans les tables sources alors que la tâche est à l'arrêt (par exemple, DROP COLUMN) ne seront pas capturées lorsque la tâche reprend à partir d'un moment ou d'une position antérieur(e) (SCN/LSN). Dans ce cas, les métadonnées qui existent lorsque la tâche reprend seront capturées.
- Date et heure : Définissez la date et l'heure à partir desquelles vous souhaitez démarrer la capture des modifications.
  Note Informations
  - Lorsque les journaux sont supprimés de la base de données (par ex., en raison d'une stratégie de purge), il se peut qu'il n'existe pas de journal correspondant à la date et à l'heure spécifiées. Dans ce cas, la tâche de données reprend la tâche à partir du point le plus antérieur possible après la date et l'heure spécifiées.
  - Avec le point de terminaison source IBM DB2 for LUW, cette option ne peut pas être utilisée pour démarrer des tâches Appliquer les modifications à partir d'un point précédant l'heure de début initiale de la tâche Appliquer les modifications. En d'autres termes, elle peut être utilisée uniquement pour démarrer des tâches à partir de n'importe quel point postérieur à l'heure de début initiale de la tâche Appliquer les modifications.
  - L'horodatage suit l'heure locale du poste du navigateur.
- Position du changement source (SCN ou LSN) : Spécifiez la position dans le journal à partir de laquelle reprendre le traitement des modifications. Le format de la position du changement source varie suivant votre source de données. Pour plus d'informations, consultez Comment trouver la position du changement source.
  Note Informations
  L'option Position du changement source est prise en charge uniquement avec les points de terminaison sources suivants :
  - Oracle
  - Microsoft SQL Server
  - MySQL
  - PostgreSQL
  - IBM DB2 pour z/OS
  - IBM DB2 pour LUW

Récupération des tâches

Dans la boîte de dialogue Options d'exécution avancées, sélectionnez Récupérer. Les options suivantes sont disponibles :

Récupérer via le point de contrôle stocké localement : Utilisez cette option si la récupération n'est pas possible via les tables déjà chargées. Démarrez le traitement des modifications depuis l'option (en raison de fichiers swap corrompus, par exemple). Lorsque cette option est sélectionnée, la tâche de réplication utilise les données de point de terminaison stockées dans <Data_Folder_Path>/data/tasks/<task_name>/StateManager pour récupérer la tâche.
Note Informations
Lorsque vous utilisez cette option, tenez compte des limitations et des considérations suivantes :
- Prise en charge uniquement en mode Appliquer les modifications Transactionnel et uniquement avec des cibles de données prenant en charge les transactions.
- Seules les sources de données suivantes sont prises en charge :
  - Oracle
  - Microsoft SQL Server
  - MySQL
  - PostgreSQL
  - IBM DB2 pour z/OS
  - SAP HANA
- Les tâches peuvent être récupérées uniquement lors du processus CDC (à savoir, une fois le processus Chargement complet terminé).
Récupérer via le point de contrôle stocké sur la cible : Récupérez une tâche via la valeur CHECKPOINT de la table attrep_txn_state (créée dans la base de données cible).

Exemple de valeur de point de terminaison :

checkpoint:V1#15#0000038b:000033f1:0004#0#261#0000038b:0000348b:0009#0#273

Sélectionnez cette option (et non l'option Récupérer via le point de contrôle stocké localement) si les fichiers du dossier data sont corrompus ou si le dispositif de stockage contenant le dossier data a échoué.

Pour une explication détaillée de la configuration et de la mise en œuvre de la récupération via la table attrep_txn_state, voir Récupération d'un dossier de données suite à une perte ou une corruption.

Comment trouver la position du changement source

La section suivante explique comment localiser la position du changement source pour chacune des bases de données prises en charge.

MySQL

OPTION 1 :

Exécutez :

SHOW BINARY LOGS;
Sélectionnez un fichier binlog (par ex., log.000123).
Exécutez :

SHOW BINLOG EVENTS IN 'binlog_filename';

Exemple :

SHOW BINLOG EVENTS IN 'log.000123';
Localisez la position d'une instruction BEGIN ou DDL (par ex., 1777888).

Note Informations
MySQL ne prend pas en charge une instruction "start from position" située au centre d'une transaction ; c'est pourquoi vous devez sélectionner BEGIN ou DDL.
Définissez le paramètre interne :

StartFromPosition = binlog_filename:begin_or_ddl_position

Exemple :

StartFromPosition = log.000123:1777888

OPTION 2 :

Exécutez :

SHOW MASTER STATUS;
Définissez la valeur "Start from position" comme suit :

firstColumnValue:secondColumnValue

Exemple :

mysql.007472:775

Microsoft SQL Server

Exécutez :

SELECT MAX([Current LSN]) FROM fn_dblog(null,null);

Exemple : 00002717:00000e08:0003

Oracle

Exécutez :

SELECT current_scn FROM V$DATABASE;

Exemple : 1471212002

PostgreSQL

Notez que la commande varie suivant votre version PostgreSQL.

PostgreSQL 10 et versions ultérieures

Exécutez :

SELECT * FROM pg_current_wal_lsn();

IBM DB2 pour z/OS

Spécifiez la valeur LSN, qui est la valeur RBA dans un environnement de partage sans données et la valeur LRSN dans un environnement de partage de données.

IBM DB2 pour LUW

Exécutez db2pd pour trouver le nom de journal correct.
Exécutez db2flsn avec le nom de journal renvoyé et utilisez la valeur LRI existante.

Voir aussi : Reprise ou démarrage d'une tâche depuis LRI dans un environnement pureScale

Pour plus d'informations, voir "Reprise ou démarrage d'une tâche à partir de LRI dans un environnement pureScale" dans l'aide Replicate.

Récupération d'un dossier de données suite à une perte ou une corruption

En fonctionnement normal, l'état déplacement est stocké à l'emplacement suivant :

<Data_Folder_Path>/data/tasks/<task_name>/StateManager

Cela permet la récupération des tâches qui ne peuvent pas reprendre normalement (en raison de fichiers swap corrompus, par exemple) via l'option Récupérer via le point de contrôle stocké localement susmentionnée. En revanche, si les fichiers du dossier data sont corrompus ou si le dispositif de stockage contenant le dossier data échoue, les tâches doivent être récupérées via l'option Récupérer via le point de contrôle stocké sur la cible.

Considérations générales et restrictions

Lorsque vous utilisez cette option, tenez compte des limitations et des considérations suivantes :

Cette option est disponible uniquement si l'option Enregistrer les données de récupération de la tâche dans la base de données cible a été activée dans l'onglet Modifier le réglage du traitement des paramètres de la tâche avant la fin de la tâche CDC.
Le mode Appliquer les modifications doit être défini sur Transactionnel.
Seuls les types de source de données suivants sont pris en charge :
- Amazon RDS pour MySQL
- Amazon RDS pour PostgreSQL
- Amazon RDS pour SQL
- AWS Aurora Cloud pour PostgreSQL
- Google Cloud SQL pour MySQL
- Google Cloud SQL pour PostgreSQL
- IBM DB2 pour z/OS
- Base de données Microsoft Azure pour MySQL
- Instance gérée SQL Microsoft Azure
- Microsoft SQL Server
- MySQL
- Oracle
- PostrgreSQL
- SAP HANA
Seul le type de cible Microsoft SQL Server est supporté.
Les tâches peuvent être récupérées uniquement lors du processus CDC (une fois le processus Chargement complet terminé).

Configuration et démarrage de la récupération d'une tâche

Pour que la récupération réussisse, il faut que les journaux de transactions de bases de données sources soient disponibles à partir du point auquel la tâche a échoué.

Pour configurer une tâche à des fins de récupération

Assurez-vous d'activer l'option Enregistrer les données de récupération de la tâche dans la base de données cible dans l'onglet Modifier le réglage du traitement des paramètres de la tâche. Cette option peut être activée à tout moment lors du processus CDC, à condition d'être activé avant la fin du processus CDC.
Exécutez la tâche.

Outre l'écriture dans les tables sources sélectionnées, la tâche écrira les données du point de terminaison dans la table attrep_txn_state de la base de données cible (et créera automatiquement la table si elle ne l'a pas déjà été par une autre tâche).

Pour démarrer la récupération

Accédez à la table attrep_txn_state dans la base de données cible et localisez la tâche en échec dans la colonne TASK_NAME. S'il existe des tâches portant le même nom en cours d'exécution sur plusieurs serveurs Qlik Talend Data Integration, vous devrez également localiser le serveur approprié dans la colonne SERVER_NAME. Après avoir localisé la tâche en question, copiez la valeur dans la colonne CHECKPOINT correspondante.
Sélectionnez l'option Récupérer via le point de contrôle stocké sur la cible, puis fournissez la valeur CHECKPOINT (en la collant, de préférence) comme décrit ci-dessus.
Cliquez sur OK pour démarrer la récupération.

Lors de la récupération, la tâche de réplication n'écrit rien dans la base de données cible tant qu'elle n'a pas identifié l'événement de validation correspondant à la valeur CHECKPOINT. Une fois qu'elle a identifié l'événement de validation CHECKPOINT, la récupération s'effectue et la tâche reprend son fonctionnement standard.

Cette page vous a-t-elle aidé ?

Si vous rencontrez des problèmes sur cette page ou dans son contenu – une faute de frappe, une étape manquante ou une erreur technique – dites-nous comment nous améliorer !

Laissez vos commentaires ici