Aller au contenu principal

Bridge

Copier un sous-ensemble de donnees d'une connexion source vers une connexion cible, avec anonymisation optionnelle au passage.

Quand l'utiliser​

  • Refresh staging avec une copie anonymisee de prod.
  • Snapshot de prod vers une DB d'investigation hors prod.
  • Cloner un dataset client pour reproduction de bug.

Workflow rapide​

  1. Bridge -> choisir source + cible. Les deux doivent etre des connexions du projet.
  2. Selectionner les tables (toutes ou un subset).
  3. Optionnel : appliquer un AnonymizationConfig au passage. Recommande pour prod -> staging.
  4. Optionnel : filtrer (WHERE created_at > '2026-01-01').
  5. Dry-run pour voir les volumes par table.
  6. Si l'environnement cible est prod : approval requis (policy par defaut).
  7. Executer. Auralith stream les lignes par batch avec FK ordering.

Concepts cles​

  • Source / cible : deux connexions du meme projet. Cross-project non supporte (volontaire, pour tenant isolation).
  • AnonymizationConfig : reutilise les memes strategies que la feature Anonymisation.
  • Streaming par batch : les lignes ne sont jamais entierement chargees en memoire. Permet de gerer des millions de lignes.

Pieges courants​

  • Schemas divergents : si la cible a une colonne en plus, le bridge ignore. Si la cible a moins de colonnes, le bridge ne sait pas ou mettre les valeurs source. Recommande : meme schema (utilisez Migrations en amont).
  • PK collisions : la cible doit etre vide ou avoir des IDs disjoints. Auralith ne fait pas d'UPSERT, il INSERT. Si conflit, l'execution echoue.
  • Couts en transit : pour des DBs RDS / Aurora cross-region, le trafic est facture. Lancez le bridge depuis un host dans le meme VPC que la cible.

API​

curl -X POST https://app.auralith.io/api/v1/projects/{pid}/bridge/run \
  -H "Authorization: Bearer $API_KEY" \
  -d '{
    "source_connection_id": "...",
    "target_connection_id": "...",
    "tables": ["users", "orders"],
    "anonymize_config_id": "...",
    "where_filter": null
  }'

Voir aussi​