Elasticsearch managé : migration zéro interruption via snapshot, restore et parallélisation

Sanity checks fonctionnels

10 requêtes « business » (marque, référence, catégorie, produit avec accent, fautes de frappe)
vérification facettes (ex. prix, disponibilité, attributs)

Comparaison sur corpus réel

rejouer un échantillon de requêtes depuis les logs applicatifs (si disponibles)
mesurer : taux de « 0 résultat », divergences top-N, temps de réponse

Performance & saturation

p95/p99 de search et indexing
rejets thread_pool.search / thread_pool.write, erreurs 429/503

En pratique, faites des comparaisons automatisées entre source et cible sur un corpus de requêtes réel (logs de recherche) : taux de zéro résultat, top-N divergents, distribution de latence.

Pour aider à « décider » (et pas juste observer), une table de seuils typiques à adapter à votre contexte :

Signal	Ce que ça raconte	Exemple de seuil de vigilance (à adapter)
p99 `search`	risque de soft outage UX	p99 > 2× baseline pendant > 5 min
`thread_pool.search.rejected`	saturation recherche	> 0 de façon continue
`write.rejected` / 429	backpressure indexation	hausse brutale vs baseline
Heap / GC	pression mémoire	GC longs récurrents, heap > ~75% durable
Disk watermark	allocation bloquée	shards non alloués / `yellow` persistant

Sur des workloads e-commerce, une métrique simple mais très parlante est la latence search au 99e percentile pendant la phase restore/reindex. Si elle explose, votre « zéro interruption » devient un soft outage (les pages chargent, mais trop lentement). De même, surveillez les thread_pool.search.queue et thread_pool.write.rejected. Netdata/Prometheus vous permettent de poser des alertes avant que la boutique ne se dégrade ; les deux articles Netdata/Prometheus cités plus haut servent de base.

Le rollback doit être préparé avant la bascule. Règles minimales : garder l’ancien cluster accessible (au moins en lecture), ne pas le détruire avant plusieurs jours, et conserver les snapshots T0/Tcut.

Si vous basculez par alias, le rollback est trivial : vous repointez l’alias vers l’ancien index.
Si vous basculez par endpoint DNS/HAProxy, vous revenez au backend précédent (raison de plus pour garder un TTL bas temporairement et des health checks stricts).

Dans les deux cas, documentez une checklist d’incident : qui fait quoi, quels endpoints, quels tests de smoke (10 requêtes de recherche représentatives), et quels seuils déclenchent un retour arrière.

Dernier point, souvent négligé : le provider. Un Elasticsearch managé peut être en réalité un OpenSearch managé, ou l’inverse, et les garanties de compatibilité snapshot ne sont pas interchangeables. Si vous êtes dans ce cas (ou si vous migrez entre distributions), lisez OVHcloud Managed OpenSearch : moteur NoSQL managé pour logs et recherche et partez du principe que vous devrez passer par des exports logiques (reindex) plutôt que par restore direct.

———————————————————————

Pour une boutique PrestaShop, ce runbook s’intègre bien dans une stratégie globale de migration et de durcissement : vous gérez un composant critique (recherche) qui impacte à la fois l’UX, le SEO interne, et la charge serveur. L’idée n’est pas d’avoir « un cluster qui répond », mais un cluster qui répond avec la même pertinence, les mêmes garanties de fraîcheur, et une latence stable pendant les opérations.

Si vous êtes en train de planifier une refonte/migration plus large, la checklist Migration PrestaShop : checklist d’audit thème, modules, hooks et overrides est un bon garde-fou côté applicatif.

———————————————————————

Comparaison volumétrique

docs.count par index (source vs cible)
top 10 des indices par taille et par nb de docs

Sanity checks fonctionnels

10 requêtes « business » (marque, référence, catégorie, produit avec accent, fautes de frappe)
vérification facettes (ex. prix, disponibilité, attributs)

Comparaison sur corpus réel

rejouer un échantillon de requêtes depuis les logs applicatifs (si disponibles)
mesurer : taux de « 0 résultat », divergences top-N, temps de réponse

Performance & saturation

p95/p99 de search et indexing
rejets thread_pool.search / thread_pool.write, erreurs 429/503

En pratique, faites des comparaisons automatisées entre source et cible sur un corpus de requêtes réel (logs de recherche) : taux de zéro résultat, top-N divergents, distribution de latence.

Pour aider à « décider » (et pas juste observer), une table de seuils typiques à adapter à votre contexte :

Signal	Ce que ça raconte	Exemple de seuil de vigilance (à adapter)
p99 `search`	risque de soft outage UX	p99 > 2× baseline pendant > 5 min
`thread_pool.search.rejected`	saturation recherche	> 0 de façon continue
`write.rejected` / 429	backpressure indexation	hausse brutale vs baseline
Heap / GC	pression mémoire	GC longs récurrents, heap > ~75% durable
Disk watermark	allocation bloquée	shards non alloués / `yellow` persistant

Si vous basculez par alias, le rollback est trivial : vous repointez l’alias vers l’ancien index.
Si vous basculez par endpoint DNS/HAProxy, vous revenez au backend précédent (raison de plus pour garder un TTL bas temporairement et des health checks stricts).

———————————————————————

Comparaison sur corpus réel

rejouer un échantillon de requêtes depuis les logs applicatifs (si disponibles)
mesurer : taux de « 0 résultat », divergences top-N, temps de réponse

Performance & saturation

p95/p99 de search et indexing
rejets thread_pool.search / thread_pool.write, erreurs 429/503

En pratique, faites des comparaisons automatisées entre source et cible sur un corpus de requêtes réel (logs de recherche) : taux de zéro résultat, top-N divergents, distribution de latence.

Pour aider à « décider » (et pas juste observer), une table de seuils typiques à adapter à votre contexte :

Signal	Ce que ça raconte	Exemple de seuil de vigilance (à adapter)
p99 `search`	risque de soft outage UX	p99 > 2× baseline pendant > 5 min
`thread_pool.search.rejected`	saturation recherche	> 0 de façon continue
`write.rejected` / 429	backpressure indexation	hausse brutale vs baseline
Heap / GC	pression mémoire	GC longs récurrents, heap > ~75% durable
Disk watermark	allocation bloquée	shards non alloués / `yellow` persistant

Si vous basculez par alias, le rollback est trivial : vous repointez l’alias vers l’ancien index.
Si vous basculez par endpoint DNS/HAProxy, vous revenez au backend précédent (raison de plus pour garder un TTL bas temporairement et des health checks stricts).

———————————————————————

Comparaison volumétrique

docs.count par index (source vs cible)
top 10 des indices par taille et par nb de docs

Sanity checks fonctionnels

10 requêtes « business » (marque, référence, catégorie, produit avec accent, fautes de frappe)
vérification facettes (ex. prix, disponibilité, attributs)

Comparaison sur corpus réel

rejouer un échantillon de requêtes depuis les logs applicatifs (si disponibles)
mesurer : taux de « 0 résultat », divergences top-N, temps de réponse

Performance & saturation

p95/p99 de search et indexing
rejets thread_pool.search / thread_pool.write, erreurs 429/503

En pratique, faites des comparaisons automatisées entre source et cible sur un corpus de requêtes réel (logs de recherche) : taux de zéro résultat, top-N divergents, distribution de latence.

Pour aider à « décider » (et pas juste observer), une table de seuils typiques à adapter à votre contexte :

Signal	Ce que ça raconte	Exemple de seuil de vigilance (à adapter)
p99 `search`	risque de soft outage UX	p99 > 2× baseline pendant > 5 min
`thread_pool.search.rejected`	saturation recherche	> 0 de façon continue
`write.rejected` / 429	backpressure indexation	hausse brutale vs baseline
Heap / GC	pression mémoire	GC longs récurrents, heap > ~75% durable
Disk watermark	allocation bloquée	shards non alloués / `yellow` persistant

Si vous basculez par alias, le rollback est trivial : vous repointez l’alias vers l’ancien index.
Si vous basculez par endpoint DNS/HAProxy, vous revenez au backend précédent (raison de plus pour garder un TTL bas temporairement et des health checks stricts).

———————————————————————

Sanity checks fonctionnels

10 requêtes « business » (marque, référence, catégorie, produit avec accent, fautes de frappe)
vérification facettes (ex. prix, disponibilité, attributs)

Comparaison sur corpus réel

rejouer un échantillon de requêtes depuis les logs applicatifs (si disponibles)
mesurer : taux de « 0 résultat », divergences top-N, temps de réponse

Performance & saturation

p95/p99 de search et indexing
rejets thread_pool.search / thread_pool.write, erreurs 429/503

En pratique, faites des comparaisons automatisées entre source et cible sur un corpus de requêtes réel (logs de recherche) : taux de zéro résultat, top-N divergents, distribution de latence.

Pour aider à « décider » (et pas juste observer), une table de seuils typiques à adapter à votre contexte :

Signal	Ce que ça raconte	Exemple de seuil de vigilance (à adapter)
p99 `search`	risque de soft outage UX	p99 > 2× baseline pendant > 5 min
`thread_pool.search.rejected`	saturation recherche	> 0 de façon continue
`write.rejected` / 429	backpressure indexation	hausse brutale vs baseline
Heap / GC	pression mémoire	GC longs récurrents, heap > ~75% durable
Disk watermark	allocation bloquée	shards non alloués / `yellow` persistant

Si vous basculez par alias, le rollback est trivial : vous repointez l’alias vers l’ancien index.
Si vous basculez par endpoint DNS/HAProxy, vous revenez au backend précédent (raison de plus pour garder un TTL bas temporairement et des health checks stricts).

———————————————————————

Comparaison volumétrique

docs.count par index (source vs cible)
top 10 des indices par taille et par nb de docs

Sanity checks fonctionnels

10 requêtes « business » (marque, référence, catégorie, produit avec accent, fautes de frappe)
vérification facettes (ex. prix, disponibilité, attributs)

Comparaison sur corpus réel

rejouer un échantillon de requêtes depuis les logs applicatifs (si disponibles)
mesurer : taux de « 0 résultat », divergences top-N, temps de réponse

Performance & saturation

p95/p99 de search et indexing
rejets thread_pool.search / thread_pool.write, erreurs 429/503

En pratique, faites des comparaisons automatisées entre source et cible sur un corpus de requêtes réel (logs de recherche) : taux de zéro résultat, top-N divergents, distribution de latence.

Pour aider à « décider » (et pas juste observer), une table de seuils typiques à adapter à votre contexte :

Signal	Ce que ça raconte	Exemple de seuil de vigilance (à adapter)
p99 `search`	risque de soft outage UX	p99 > 2× baseline pendant > 5 min
`thread_pool.search.rejected`	saturation recherche	> 0 de façon continue
`write.rejected` / 429	backpressure indexation	hausse brutale vs baseline
Heap / GC	pression mémoire	GC longs récurrents, heap > ~75% durable
Disk watermark	allocation bloquée	shards non alloués / `yellow` persistant

Si vous basculez par alias, le rollback est trivial : vous repointez l’alias vers l’ancien index.
Si vous basculez par endpoint DNS/HAProxy, vous revenez au backend précédent (raison de plus pour garder un TTL bas temporairement et des health checks stricts).

———————————————————————

Comparaison sur corpus réel

rejouer un échantillon de requêtes depuis les logs applicatifs (si disponibles)
mesurer : taux de « 0 résultat », divergences top-N, temps de réponse

Performance & saturation

p95/p99 de search et indexing
rejets thread_pool.search / thread_pool.write, erreurs 429/503

En pratique, faites des comparaisons automatisées entre source et cible sur un corpus de requêtes réel (logs de recherche) : taux de zéro résultat, top-N divergents, distribution de latence.

Pour aider à « décider » (et pas juste observer), une table de seuils typiques à adapter à votre contexte :

Signal	Ce que ça raconte	Exemple de seuil de vigilance (à adapter)
p99 `search`	risque de soft outage UX	p99 > 2× baseline pendant > 5 min
`thread_pool.search.rejected`	saturation recherche	> 0 de façon continue
`write.rejected` / 429	backpressure indexation	hausse brutale vs baseline
Heap / GC	pression mémoire	GC longs récurrents, heap > ~75% durable
Disk watermark	allocation bloquée	shards non alloués / `yellow` persistant

Si vous basculez par alias, le rollback est trivial : vous repointez l’alias vers l’ancien index.
Si vous basculez par endpoint DNS/HAProxy, vous revenez au backend précédent (raison de plus pour garder un TTL bas temporairement et des health checks stricts).

———————————————————————

Sanity checks fonctionnels

10 requêtes « business » (marque, référence, catégorie, produit avec accent, fautes de frappe)
vérification facettes (ex. prix, disponibilité, attributs)

Comparaison sur corpus réel

rejouer un échantillon de requêtes depuis les logs applicatifs (si disponibles)
mesurer : taux de « 0 résultat », divergences top-N, temps de réponse

Performance & saturation

p95/p99 de search et indexing
rejets thread_pool.search / thread_pool.write, erreurs 429/503

En pratique, faites des comparaisons automatisées entre source et cible sur un corpus de requêtes réel (logs de recherche) : taux de zéro résultat, top-N divergents, distribution de latence.

Pour aider à « décider » (et pas juste observer), une table de seuils typiques à adapter à votre contexte :

Signal	Ce que ça raconte	Exemple de seuil de vigilance (à adapter)
p99 `search`	risque de soft outage UX	p99 > 2× baseline pendant > 5 min
`thread_pool.search.rejected`	saturation recherche	> 0 de façon continue
`write.rejected` / 429	backpressure indexation	hausse brutale vs baseline
Heap / GC	pression mémoire	GC longs récurrents, heap > ~75% durable
Disk watermark	allocation bloquée	shards non alloués / `yellow` persistant

Si vous basculez par alias, le rollback est trivial : vous repointez l’alias vers l’ancien index.
Si vous basculez par endpoint DNS/HAProxy, vous revenez au backend précédent (raison de plus pour garder un TTL bas temporairement et des health checks stricts).

———————————————————————

Comparaison volumétrique

docs.count par index (source vs cible)
top 10 des indices par taille et par nb de docs

Sanity checks fonctionnels

10 requêtes « business » (marque, référence, catégorie, produit avec accent, fautes de frappe)
vérification facettes (ex. prix, disponibilité, attributs)

Comparaison sur corpus réel

rejouer un échantillon de requêtes depuis les logs applicatifs (si disponibles)
mesurer : taux de « 0 résultat », divergences top-N, temps de réponse

Performance & saturation

p95/p99 de search et indexing
rejets thread_pool.search / thread_pool.write, erreurs 429/503

En pratique, faites des comparaisons automatisées entre source et cible sur un corpus de requêtes réel (logs de recherche) : taux de zéro résultat, top-N divergents, distribution de latence.

Pour aider à « décider » (et pas juste observer), une table de seuils typiques à adapter à votre contexte :

Signal	Ce que ça raconte	Exemple de seuil de vigilance (à adapter)
p99 `search`	risque de soft outage UX	p99 > 2× baseline pendant > 5 min
`thread_pool.search.rejected`	saturation recherche	> 0 de façon continue
`write.rejected` / 429	backpressure indexation	hausse brutale vs baseline
Heap / GC	pression mémoire	GC longs récurrents, heap > ~75% durable
Disk watermark	allocation bloquée	shards non alloués / `yellow` persistant

Si vous basculez par alias, le rollback est trivial : vous repointez l’alias vers l’ancien index.
Si vous basculez par endpoint DNS/HAProxy, vous revenez au backend précédent (raison de plus pour garder un TTL bas temporairement et des health checks stricts).

———————————————————————

Table des matières :

Elasticsearch managé : ce qui change réellement pendant une migration

Sur un Elasticsearch managé (Elastic Cloud, AWS/OpenSearch Service, OVHcloud Managed OpenSearch, etc.), la migration n’est pas un simple « rsync de data/ ». Vous n’avez généralement pas d’accès au filesystem, peu ou pas de contrôle sur certains paramètres de bas niveau, et des contraintes fortes sur les plugins (souvent une liste blanche). La conséquence directe : votre plan de migration doit reposer sur des primitives supportées par l’API (snapshot/restore, reindex, aliases) et sur l’observabilité, pas sur des bricolages hors bande.

Un point qui surprend souvent : en managé, certains comportements « évidents » en self-hosted deviennent des SLO contractuels (et donc des limites réelles). Exemples typiques :

Fenêtres de maintenance imposées (patchs, redémarrages, opérations de scaling).
Quotas (nombre de snapshots, fréquence, bande passante snapshot/restore, taille max de requêtes).
Sécurité intégrée (TLS obligatoire, auth par API key/IAM, restrictions IP/VPC, rotation de certificats).
Paramètres bloqués (certains cluster.* non modifiables, politiques d’auto-scaling gérées par le provider).

« Zéro interruption » ne veut pas dire « zéro risque ». Dans la pratique, l’objectif est : aucun downtime applicatif (les requêtes continuent de répondre) et une fenêtre d’incohérence fonctionnelle bornée (ex. quelques secondes de retard d’indexation) acceptable pour votre cas d’usage. Pour une boutique PrestaShop, typiquement : un moteur de recherche (autosuggest / live search) tolère quelques secondes de décalage, mais un cluster qui sert aussi des logs ou des métriques peut exiger une continuité plus stricte.

Enfin, le managé ajoute une couche de réseau et de sécurité : endpoints publics/privés, TLS obligatoire, auth par API key/IAM, et parfois des limites de débit sur snapshot/restore. Si vous avez déjà dû gérer des bascules DNS/TTL ou un reverse-proxy applicatif, vous connaissez l’essentiel des pièges : propagation, caches clients, et health checks. À ce sujet, les runbooks autour de HAProxy : configuration avancée ACL, health checks et sticky sessions sont directement réutilisables.

GEO (à garder en tête sans en faire une religion) : la localisation de votre cluster cible joue sur la latence perçue et sur la conformité. Un cluster dans la même zone géographique que votre front (ex. clients majoritairement en France, infra en région parisienne) réduit les aller-retours et simplifie les discussions sur la résidence des données. C’est surtout vrai si vos requêtes de recherche sont appelées sur chaque page catégorie et sur l’autocomplétion : quelques dizaines de millisecondes de RTT en plus peuvent devenir visibles.

———————————————————————

Préflight : compatibilités de versions, plugins, mappings et analyzers

Avant de parler snapshot, il faut verrouiller la compatibilité. La documentation Elastic est claire : on ne peut généralement pas restaurer un snapshot vers une version antérieure. Cela impose, selon vos versions source/cible, un plan en 2 étapes (upgrade de l’ancien cluster, puis snapshot, puis restore) ou l’usage de reindex depuis remote (documentation Elastic, Snapshot and restore : Snapshot and restore (Elastic)).

Deuxième verrou : plugins et analyzers. Beaucoup de migrations « cassent » parce que l’index utilise un analyzer (icu, kuromoji, analysis-phonetic, custom token filter) indisponible sur la cible managée. Dans ce cas, le restore échoue, ou pire : l’index remonte mais certaines requêtes analysées différemment font chuter la pertinence.

Commandes minimales à exécuter sur la source (adaptez l’auth) :

curl -s https://SRC/_nodes/plugins?pretty
curl -s https://SRC/_index_template?pretty
curl -s https://SRC/_ilm/policy?pretty
curl -s https://SRC/_cat/indices?v

Troisième point : l’état « cluster » et les indices système. En Elasticsearch récent, les snapshots peuvent inclure des feature states (sécurité, Kibana, etc.). Restaurer l’état global « comme en self-hosted » est rarement une bonne idée en managé : vous risquez d’écraser des settings gérés par le provider (routing, security realms, etc.). En général, on privilégie include_global_state=false et on recrée explicitement sur la cible : templates, ILM, ingest pipelines, rôles, users (ou on les gère par IaC).

Pour rendre ce préflight actionnable, voici une checklist courte (souvent suffisante pour éviter 80% des surprises) :

Versions / distribution
Source et cible : Elasticsearch vs OpenSearch ? (ne présumez pas de la compatibilité snapshot entre distributions)
Version cible >= version source (sinon, plan d’upgrade ou reindex)
Index templates / component templates
Les templates existent-ils sur la cible avant restore/reindex ?
Les index_patterns couvrent-ils les nouveaux noms (si vous renommez) ?
Mappings
Champs keyword vs text, normalizers, ignore_above
Champs date (formats) et scaled_float (scaling_factor)
Analyse linguistique
Token filters non supportés ? (ex. plugin phonétique absent)
Stopwords / synonyms : fichiers externes autorisés ou non en managé ?
ILM & rollover
Politiques ILM présentes, rollover_alias correct, droits d’écriture sur l’alias
Pipelines d’ingestion
ingest pipelines existants (grok, geoip, enrich) et compatibilité des processors
Sécurité & accès
Rôles/permissions, API keys, IP allowlist/VPC peering
Capacité
Nombre de shards, taille par shard, disque disponible, réplications prévues

Cas e-commerce concret : si votre moteur sert la recherche produit PrestaShop (live search, facettes, autosuggest), les templates et analyzers conditionnent le ranking et les temps de réponse. Une migration « techniquement verte » mais avec un analyzer différent se voit immédiatement dans les résultats (ex. gestion des pluriels, des accents, des tirets, du stemming). Vous pouvez recouper les attentes fonctionnelles côté boutique avec les contraintes techniques côté cluster via Recherche interne PrestaShop : live search, tolérance fautes et tri commercial.

———————————————————————

Snapshot : repository, chiffrement, throttling et cohérence

Le snapshot est la brique de base pour une migration rapide parce qu’il copie les segments Lucene (donc très efficace pour des volumes importants). Point important côté comportement : les snapshots sont incrémentaux au niveau des segments, ce qui rend les snapshots suivants beaucoup plus rapides après un premier snapshot « lourd » (documentation Elastic, Snapshot and restore : Snapshot and restore (Elastic)).

Sur du managé, le repository est presque toujours un objet storage (S3, Azure Blob, GCS, Swift/S3-compatible). Exemple d’API (self-managed ou managé qui expose l’API) pour déclarer un repo S3 ; côté managé, cette étape est parfois faite dans la console du provider :

curl -X PUT https://SRC/_snapshot/migrepo \
  -H 'Content-Type: application/json' \
  -d '{
    "type": "s3",
    "settings": {
      "bucket": "es-mig-prod",
      "base_path": "snapshots/2026-08",
      "server_side_encryption": true
    }
  }'

Avant de lancer « en prod », ajoutez deux vérifications simples (elles évitent des heures perdues sur un repo mal configuré) :

curl -s https://SRC/_snapshot/migrepo/_verify?pretty
curl -s https://SRC/_snapshot/migrepo?pretty

Ensuite, déclenchez un snapshot sans bloquer votre terminal (et sans figer l’app). Le point de vigilance est la charge I/O : snapshot = lecture massive + upload ; si votre cluster est déjà limite en latence (99p), vous allez ressentir la pression. Exemple :

curl -X PUT "https://SRC/_snapshot/migrepo/snap-0001?wait_for_completion=false" \
  -H 'Content-Type: application/json' \
  -d '{
    "indices": "prod-*,logs-*",
    "include_global_state": false,
    "ignore_unavailable": true
  }'

Suivi minimal (pour ne pas piloter à l’aveugle) :

curl -s https://SRC/_snapshot/migrepo/snap-0001?pretty
curl -s https://SRC/_cat/snapshots/migrepo?v

Deux réglages font souvent la différence sur des clusters managés : le throttling snapshot/restore (ex. max_snapshot_bytes_per_sec, max_restore_bytes_per_sec) et la planification (lancer le gros snapshot hors pic). Même si vous visez « zéro interruption », vous devez raisonner en budget de latence : si votre recherche produit est déjà sous tension, un snapshot au mauvais moment peut dégrader le TTFB et l’expérience utilisateur.

Mini-scenario réaliste : une boutique B2C en France avec pics 12h-14h et 19h-22h. Vous lancez le snapshot à 19h30, le cluster reste « up » mais le 99p search double, l’autosuggest devient erratique, et vous prenez un « incident SEO » (taux de rebond en hausse). La même opération à 02h00 passe sans bruit. La migration « zéro downtime » se gagne souvent sur ce genre de décisions.

Enfin, en GEO : placez le bucket/containers de snapshots dans la même région cloud que le cluster source/cible si possible, pour limiter les coûts d’egress et la latence de transfert. Sur certains providers, un repository cross-region fonctionne… mais le temps de migration et la facture peuvent exploser.

Pour replacer ça dans une vision plus large performance côté boutique, Cache PrestaShop : stratégie 2026 OPcache, Redis, Varnish et CDN aide à raisonner « bout en bout » (front → back → ES).

———————————————————————

Restore : restauration sélective et parallélisation côté cluster

Le restore est l’étape où la plupart des migrations « se plantent » pour de mauvaises raisons : collision de noms d’indices, settings incompatibles, ou allocation de shards qui n’aboutit pas (watermarks disque, tiering absent, nombre de nœuds insuffisant). En managé, partez du principe que vous devrez restaurer sélectivement et souvent renommer pour garder la possibilité de comparer source vs cible.

Avant même le premier restore, faites un rapide dimensionnement « anti-mur » :

Espace disque : la cible doit pouvoir accueillir le volume restauré + marge (segments, merges, translog).
Nombre de shards : trop de shards = overhead (mémoire/threads), restore plus lent.
Réplicas : mettez-les à 0 pendant restore/reindex si votre tolérance de risque le permet, puis remontez.
Watermarks : si le provider impose des seuils, un restore peut rester bloqué en yellow/red faute d’allocation.

Exemple de restore avec renommage et override de settings (typiquement : remettre number_of_replicas=0 pendant l’ingestion pour accélérer, puis remonter les replicas après stabilisation) :

curl -X POST https://DST/_snapshot/migrepo/snap-0001/_restore \
  -H 'Content-Type: application/json' \
  -d '{
    "indices": "prod-*",
    "include_global_state": false,
    "rename_pattern": "prod-(.*)",
    "rename_replacement": "mig-prod-$1",
    "index_settings": {
      "index.number_of_replicas": 0,
      "index.refresh_interval": "30s"
    }
  }'

Après lancement, ne vous contentez pas d’un cluster green. Regardez où ça coince :

curl -s https://DST/_cat/recovery?v
curl -s https://DST/_cat/shards/mig-prod-*?v
curl -s https://DST/_cluster/health?pretty

Et si un index reste non alloué, l’API d’explication est souvent le chemin le plus court :

curl -s https://DST/_cluster/allocation/explain?pretty

La parallélisation du restore se joue à deux niveaux : (1) en lançant plusieurs restores (par groupes d’indices indépendants) et (2) en autorisant plus de recoveries simultanées. Les settings typiques (à manier avec prudence, car vous pouvez saturer CPU/disk/network) :

cluster.routing.allocation.node_concurrent_recoveries
cluster.routing.allocation.node_initial_primaries_recoveries
indices.recovery.max_bytes_per_sec

Le pattern pragmatique : augmentez progressivement, observez la latence et le taux d’erreurs, puis ajustez. Sur des clusters orientés e-commerce (beaucoup de petites recherches), vous voulez éviter la saturation des threads de recherche pendant les recoveries.

Astuce simple mais efficace : restaurez d’abord les indices « volumineux mais peu consultés » (ex. historique, logs, anciens indices rollovers), puis les indices « chauds » (produits, catégories, autosuggest). Cela permet de réserver des ressources à ce qui impacte l’UX.

Si vous avez un environnement de monitoring déjà en place, vous pouvez brancher les dashboards et alertes très tôt. Les articles Netdata : intégrer Prometheus, SNMP et StatsD pour tout surveiller et Prometheus : configuration des alertes, métriques et requêtes PromQL donnent une base solide pour mettre des seuils sur : latence 95p/99p, heap, GC, saturation CPU, disk watermarks et erreurs HTTP 429/503.

———————————————————————

Delta sync sans interruption : dual-write, reindex parallélisé et alias atomiques

Le snapshot/restore vous donne un état T0. Pour une migration réellement « zéro interruption », il faut ensuite gérer le delta (T0 → Tcut). Vous avez quatre options, par ordre de robustesse, et toutes ne sont pas disponibles en managé selon le provider :

CCR (Cross-Cluster Replication) si vous êtes sur une offre Elastic qui le supporte (réplication quasi temps réel).
Dual-write applicatif (votre pipeline d’indexation écrit sur source + cible pendant la bascule).
Reindex depuis remote (copie logique via _reindex), utile si la compatibilité snapshot est compliquée.
Rebuild complet depuis la source de vérité (souvent MySQL pour un index produit PrestaShop), acceptable si l’index est dérivé et reconstruisible.

Pour de gros indices, la parallélisation côté reindex est indispensable : l’API _reindex supporte le sliced scroll pour exécuter des tranches en parallèle (documentation Elastic, Reindex API : Reindex API (Elastic)). Exemple (à adapter) avec slices automatiques ; attention : cette opération consomme fortement le cluster source et le cluster cible.

curl -X POST https://DST/_reindex?wait_for_completion=false \
  -H 'Content-Type: application/json' \
  -d '{
    "source": {
      "remote": {
        "host": "https://SRC"
      },
      "index": "prod-products"
    },
    "dest": {
      "index": "mig-prod-products"
    },
    "conflicts": "proceed",
    "slices": "auto"
  }'

Quand préférer le dual-write ? Quand vous avez une chaîne d’indexation événementielle (ex. message queue, jobs asynchrones) et que vous pouvez rendre les écritures idempotentes (même doc écrit deux fois → même résultat). En e-commerce, c’est souvent le cas : un changement de prix/stock/attribut produit peut être rejoué sans danger si l’ID document est stable.

Quand préférer le rebuild complet ? Quand l’index est 100% dérivé (recalculable) et que vous avez déjà un job de reconstruction (batch nocturne, commande CLI, pipeline ETL). C’est parfois plus sûr qu’un reindex cross-cluster si vous migrez entre distributions (Elasticsearch ↔ OpenSearch) ou si le mapping doit évoluer.

La bascule « propre » se fait avec des aliases atomiques. Au lieu de changer le code ou les endpoints partout, vous pointez vos requêtes vers un alias stable (ex. prod-products-current) puis vous swappez l’alias de prod-products vers mig-prod-products. L’API _aliases est atomique : si vous batchiez correctement, vous évitez la fenêtre où l’alias n’existe plus.

curl -X POST https://DST/_aliases \
  -H 'Content-Type: application/json' \
  -d '{
    "actions": [
      { "remove": { "index": "prod-products", "alias": "prod-products-current" } },
      { "add":    { "index": "mig-prod-products", "alias": "prod-products-current" } }
    ]
  }'

Si votre application doit aussi basculer d’endpoint (nouveau cluster, nouveau domaine), anticipez le réseau : TTL, caches, et éventuels reverse-proxy. Pour la partie DNS/propagation, Zone DNS OVHcloud : propagation, TTL et bonnes pratiques de configuration est directement actionnable.

———————————————————————

Validation, observabilité et rollback : ce que vous devez mesurer (et garder)

La validation ne se limite pas à « cluster green ». Vous devez contrôler : (1) intégrité des données (doc counts, checks sur des clés), (2) fonctionnel (pertinence, scoring, filtres), (3) performance (latence, throughput, cache hit), (4) stabilité (GC, heap, file descriptors, rejections).

Une séquence de validation simple, qui passe bien en runbook d’astreinte :

Performance & saturation

p95/p99 de search et indexing
rejets thread_pool.search / thread_pool.write, erreurs 429/503

En pratique, faites des comparaisons automatisées entre source et cible sur un corpus de requêtes réel (logs de recherche) : taux de zéro résultat, top-N divergents, distribution de latence.

Pour aider à « décider » (et pas juste observer), une table de seuils typiques à adapter à votre contexte :

Signal	Ce que ça raconte	Exemple de seuil de vigilance (à adapter)
p99 `search`	risque de soft outage UX	p99 > 2× baseline pendant > 5 min
`thread_pool.search.rejected`	saturation recherche	> 0 de façon continue
`write.rejected` / 429	backpressure indexation	hausse brutale vs baseline
Heap / GC	pression mémoire	GC longs récurrents, heap > ~75% durable
Disk watermark	allocation bloquée	shards non alloués / `yellow` persistant

Si vous basculez par alias, le rollback est trivial : vous repointez l’alias vers l’ancien index.
Si vous basculez par endpoint DNS/HAProxy, vous revenez au backend précédent (raison de plus pour garder un TTL bas temporairement et des health checks stricts).

———————————————————————

Comparaison sur corpus réel

rejouer un échantillon de requêtes depuis les logs applicatifs (si disponibles)
mesurer : taux de « 0 résultat », divergences top-N, temps de réponse

Performance & saturation

p95/p99 de search et indexing
rejets thread_pool.search / thread_pool.write, erreurs 429/503

En pratique, faites des comparaisons automatisées entre source et cible sur un corpus de requêtes réel (logs de recherche) : taux de zéro résultat, top-N divergents, distribution de latence.

Pour aider à « décider » (et pas juste observer), une table de seuils typiques à adapter à votre contexte :

Signal	Ce que ça raconte	Exemple de seuil de vigilance (à adapter)
p99 `search`	risque de soft outage UX	p99 > 2× baseline pendant > 5 min
`thread_pool.search.rejected`	saturation recherche	> 0 de façon continue
`write.rejected` / 429	backpressure indexation	hausse brutale vs baseline
Heap / GC	pression mémoire	GC longs récurrents, heap > ~75% durable
Disk watermark	allocation bloquée	shards non alloués / `yellow` persistant

Si vous basculez par alias, le rollback est trivial : vous repointez l’alias vers l’ancien index.
Si vous basculez par endpoint DNS/HAProxy, vous revenez au backend précédent (raison de plus pour garder un TTL bas temporairement et des health checks stricts).

———————————————————————

Sanity checks fonctionnels

10 requêtes « business » (marque, référence, catégorie, produit avec accent, fautes de frappe)
vérification facettes (ex. prix, disponibilité, attributs)

Comparaison sur corpus réel

rejouer un échantillon de requêtes depuis les logs applicatifs (si disponibles)
mesurer : taux de « 0 résultat », divergences top-N, temps de réponse

Performance & saturation

p95/p99 de search et indexing
rejets thread_pool.search / thread_pool.write, erreurs 429/503

En pratique, faites des comparaisons automatisées entre source et cible sur un corpus de requêtes réel (logs de recherche) : taux de zéro résultat, top-N divergents, distribution de latence.

Pour aider à « décider » (et pas juste observer), une table de seuils typiques à adapter à votre contexte :

Signal	Ce que ça raconte	Exemple de seuil de vigilance (à adapter)
p99 `search`	risque de soft outage UX	p99 > 2× baseline pendant > 5 min
`thread_pool.search.rejected`	saturation recherche	> 0 de façon continue
`write.rejected` / 429	backpressure indexation	hausse brutale vs baseline
Heap / GC	pression mémoire	GC longs récurrents, heap > ~75% durable
Disk watermark	allocation bloquée	shards non alloués / `yellow` persistant

Si vous basculez par alias, le rollback est trivial : vous repointez l’alias vers l’ancien index.
Si vous basculez par endpoint DNS/HAProxy, vous revenez au backend précédent (raison de plus pour garder un TTL bas temporairement et des health checks stricts).

———————————————————————

Comparaison volumétrique

docs.count par index (source vs cible)
top 10 des indices par taille et par nb de docs

Sanity checks fonctionnels

10 requêtes « business » (marque, référence, catégorie, produit avec accent, fautes de frappe)
vérification facettes (ex. prix, disponibilité, attributs)

Comparaison sur corpus réel

rejouer un échantillon de requêtes depuis les logs applicatifs (si disponibles)
mesurer : taux de « 0 résultat », divergences top-N, temps de réponse

Performance & saturation

p95/p99 de search et indexing
rejets thread_pool.search / thread_pool.write, erreurs 429/503

En pratique, faites des comparaisons automatisées entre source et cible sur un corpus de requêtes réel (logs de recherche) : taux de zéro résultat, top-N divergents, distribution de latence.

Pour aider à « décider » (et pas juste observer), une table de seuils typiques à adapter à votre contexte :

Signal	Ce que ça raconte	Exemple de seuil de vigilance (à adapter)
p99 `search`	risque de soft outage UX	p99 > 2× baseline pendant > 5 min
`thread_pool.search.rejected`	saturation recherche	> 0 de façon continue
`write.rejected` / 429	backpressure indexation	hausse brutale vs baseline
Heap / GC	pression mémoire	GC longs récurrents, heap > ~75% durable
Disk watermark	allocation bloquée	shards non alloués / `yellow` persistant

Si vous basculez par alias, le rollback est trivial : vous repointez l’alias vers l’ancien index.
Si vous basculez par endpoint DNS/HAProxy, vous revenez au backend précédent (raison de plus pour garder un TTL bas temporairement et des health checks stricts).

———————————————————————

Elasticsearch managé : migration zéro interruption via snapshot, restore et parallélisation

Elasticsearch managé : ce qui change réellement pendant une migration

Préflight : compatibilités de versions, plugins, mappings et analyzers

Snapshot : repository, chiffrement, throttling et cohérence

Restore : restauration sélective et parallélisation côté cluster

Delta sync sans interruption : dual-write, reindex parallélisé et alias atomiques

Validation, observabilité et rollback : ce que vous devez mesurer (et garder)

À lire aussi

Symfony Messenger : config transports RabbitMQ, Redis ou SQS en production

Webservice PrestaShop : sécuriser les clés API et permissions

Optimisation PrestaShop : réduire les requêtes SQL et les hooks