From 923cccdffe2d34b3c10113aee649619125c6bcd6 Mon Sep 17 00:00:00 2001 From: Lorenzo Date: Thu, 21 Aug 2025 14:30:28 +0200 Subject: [PATCH 1/5] Clarify minimal downtime data migration --- ...ta-between-elasticsearch-clusters-with-minimal-downtime.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/manage-data/migrate/migrate-data-between-elasticsearch-clusters-with-minimal-downtime.md b/manage-data/migrate/migrate-data-between-elasticsearch-clusters-with-minimal-downtime.md index dc674e8175..320dfd1b71 100644 --- a/manage-data/migrate/migrate-data-between-elasticsearch-clusters-with-minimal-downtime.md +++ b/manage-data/migrate/migrate-data-between-elasticsearch-clusters-with-minimal-downtime.md @@ -48,11 +48,11 @@ Tp complete the migration with minimal downtime, use incremental snapshots. Whil 1. **09:00**: Take the initial full snapshot of the old cluster. You can also take the initial full snapshot the day before. 2. **09:30**: Restore the snapshot to the new cluster. -3. **09:55**: Take another snapshot of the old cluster and restore it to the new cluster. Repeat this process until the snapshot and restore operations take only a few seconds or minutes. +3. **09:55**: Take another snapshot of the old cluster and restore it to the new cluster. Repeat this process until the snapshot and restore operations take only a few seconds or minutes. Remember that, when restoring indices that _already_ exist in the new cluster (e.g. to pull in recently copied data), they need to be [closed](/deploy-manage/tools/snapshot-and-restore/restore-snapshot#considerations). Also remember that the restore operation automatically opens indices, so you will likely need to close the actively-written one after restoring them. 4. **10:15**: Perform the final cutover. 1. In the old cluster, pause indexing or set indices to read-only. For details on setting indices to read-only to safely pause indexing during migration, check [Index lifecycle actions: Read-only](elasticsearch://reference/elasticsearch/index-lifecycle-actions/ilm-readonly.md). 2. Take a final snapshot. - 3. Restore the snapshot to the new cluster. + 3. Restore the snapshot to the new cluster. Again, remember that, to restore indices that already exist, they need to be closed. 4. Change ingestion and querying to the new cluster. 5. Open the indices in the new cluster. From e07dd590214911d261ce2c3b308ac6ffe14e0e22 Mon Sep 17 00:00:00 2001 From: Lorenzo Date: Thu, 21 Aug 2025 14:31:46 +0200 Subject: [PATCH 2/5] Update migrate-data-between-elasticsearch-clusters-with-minimal-downtime.md --- ...data-between-elasticsearch-clusters-with-minimal-downtime.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/manage-data/migrate/migrate-data-between-elasticsearch-clusters-with-minimal-downtime.md b/manage-data/migrate/migrate-data-between-elasticsearch-clusters-with-minimal-downtime.md index 320dfd1b71..239ee0fd1e 100644 --- a/manage-data/migrate/migrate-data-between-elasticsearch-clusters-with-minimal-downtime.md +++ b/manage-data/migrate/migrate-data-between-elasticsearch-clusters-with-minimal-downtime.md @@ -48,7 +48,7 @@ Tp complete the migration with minimal downtime, use incremental snapshots. Whil 1. **09:00**: Take the initial full snapshot of the old cluster. You can also take the initial full snapshot the day before. 2. **09:30**: Restore the snapshot to the new cluster. -3. **09:55**: Take another snapshot of the old cluster and restore it to the new cluster. Repeat this process until the snapshot and restore operations take only a few seconds or minutes. Remember that, when restoring indices that _already_ exist in the new cluster (e.g. to pull in recently copied data), they need to be [closed](/deploy-manage/tools/snapshot-and-restore/restore-snapshot#considerations). Also remember that the restore operation automatically opens indices, so you will likely need to close the actively-written one after restoring them. +3. **09:55**: Take another snapshot of the old cluster and restore it to the new cluster. Repeat this process until the snapshot and restore operations take only a few seconds or minutes. Remember that, when restoring indices that _already_ exist in the new cluster (e.g. to pull in recently copied data), they need to be [closed](/deploy-manage/tools/snapshot-and-restore/restore-snapshot#considerations). Also remember that the restore operation automatically opens indices, so you will likely need to close the actively written ones after restoring them. 4. **10:15**: Perform the final cutover. 1. In the old cluster, pause indexing or set indices to read-only. For details on setting indices to read-only to safely pause indexing during migration, check [Index lifecycle actions: Read-only](elasticsearch://reference/elasticsearch/index-lifecycle-actions/ilm-readonly.md). 2. Take a final snapshot. From 3ce6349d752bf61ccbe39f9054a4734348f266b8 Mon Sep 17 00:00:00 2001 From: Lorenzo Date: Thu, 21 Aug 2025 14:37:09 +0200 Subject: [PATCH 3/5] Update migrate-data-between-elasticsearch-clusters-with-minimal-downtime.md --- ...data-between-elasticsearch-clusters-with-minimal-downtime.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/manage-data/migrate/migrate-data-between-elasticsearch-clusters-with-minimal-downtime.md b/manage-data/migrate/migrate-data-between-elasticsearch-clusters-with-minimal-downtime.md index 239ee0fd1e..9e9202eecd 100644 --- a/manage-data/migrate/migrate-data-between-elasticsearch-clusters-with-minimal-downtime.md +++ b/manage-data/migrate/migrate-data-between-elasticsearch-clusters-with-minimal-downtime.md @@ -48,7 +48,7 @@ Tp complete the migration with minimal downtime, use incremental snapshots. Whil 1. **09:00**: Take the initial full snapshot of the old cluster. You can also take the initial full snapshot the day before. 2. **09:30**: Restore the snapshot to the new cluster. -3. **09:55**: Take another snapshot of the old cluster and restore it to the new cluster. Repeat this process until the snapshot and restore operations take only a few seconds or minutes. Remember that, when restoring indices that _already_ exist in the new cluster (e.g. to pull in recently copied data), they need to be [closed](/deploy-manage/tools/snapshot-and-restore/restore-snapshot#considerations). Also remember that the restore operation automatically opens indices, so you will likely need to close the actively written ones after restoring them. +3. **09:55**: Take another snapshot of the old cluster and restore it to the new cluster. Repeat this process until the snapshot and restore operations take only a few seconds or minutes. Remember that, when restoring indices that _already_ exist in the new cluster (e.g. to pull in recently copied data), they need to be [closed](/deploy-manage/tools/snapshot-and-restore/restore-snapshot.md#considerations). Also remember that the restore operation automatically opens indices, so you will likely need to close the actively written ones after restoring them. 4. **10:15**: Perform the final cutover. 1. In the old cluster, pause indexing or set indices to read-only. For details on setting indices to read-only to safely pause indexing during migration, check [Index lifecycle actions: Read-only](elasticsearch://reference/elasticsearch/index-lifecycle-actions/ilm-readonly.md). 2. Take a final snapshot. From 311d28657c8f642dba57739a631b1386e4d6fc69 Mon Sep 17 00:00:00 2001 From: Lorenzo Date: Thu, 21 Aug 2025 15:36:10 +0200 Subject: [PATCH 4/5] Update manage-data/migrate/migrate-data-between-elasticsearch-clusters-with-minimal-downtime.md Co-authored-by: David Kilfoyle <41695641+kilfoyle@users.noreply.github.com> --- ...data-between-elasticsearch-clusters-with-minimal-downtime.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/manage-data/migrate/migrate-data-between-elasticsearch-clusters-with-minimal-downtime.md b/manage-data/migrate/migrate-data-between-elasticsearch-clusters-with-minimal-downtime.md index 9e9202eecd..0b63ef4a11 100644 --- a/manage-data/migrate/migrate-data-between-elasticsearch-clusters-with-minimal-downtime.md +++ b/manage-data/migrate/migrate-data-between-elasticsearch-clusters-with-minimal-downtime.md @@ -48,7 +48,7 @@ Tp complete the migration with minimal downtime, use incremental snapshots. Whil 1. **09:00**: Take the initial full snapshot of the old cluster. You can also take the initial full snapshot the day before. 2. **09:30**: Restore the snapshot to the new cluster. -3. **09:55**: Take another snapshot of the old cluster and restore it to the new cluster. Repeat this process until the snapshot and restore operations take only a few seconds or minutes. Remember that, when restoring indices that _already_ exist in the new cluster (e.g. to pull in recently copied data), they need to be [closed](/deploy-manage/tools/snapshot-and-restore/restore-snapshot.md#considerations). Also remember that the restore operation automatically opens indices, so you will likely need to close the actively written ones after restoring them. +3. **09:55**: Take another snapshot of the old cluster and restore it to the new cluster. Repeat this process until the snapshot and restore operations take only a few seconds or minutes. Remember that when restoring indices that _already_ exist in the new cluster (for example, to pull in recently copied data), they first need to be [closed](/deploy-manage/tools/snapshot-and-restore/restore-snapshot.md#considerations). Also, remember that the restore operation automatically opens indices, so you will likely need to close the actively written ones after restoring them. 4. **10:15**: Perform the final cutover. 1. In the old cluster, pause indexing or set indices to read-only. For details on setting indices to read-only to safely pause indexing during migration, check [Index lifecycle actions: Read-only](elasticsearch://reference/elasticsearch/index-lifecycle-actions/ilm-readonly.md). 2. Take a final snapshot. From f01c8f562e59f1b199a6ee2c950121aceeb52022 Mon Sep 17 00:00:00 2001 From: Lorenzo Date: Thu, 21 Aug 2025 15:36:19 +0200 Subject: [PATCH 5/5] Update manage-data/migrate/migrate-data-between-elasticsearch-clusters-with-minimal-downtime.md Co-authored-by: David Kilfoyle <41695641+kilfoyle@users.noreply.github.com> --- ...data-between-elasticsearch-clusters-with-minimal-downtime.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/manage-data/migrate/migrate-data-between-elasticsearch-clusters-with-minimal-downtime.md b/manage-data/migrate/migrate-data-between-elasticsearch-clusters-with-minimal-downtime.md index 0b63ef4a11..c2f2bb82eb 100644 --- a/manage-data/migrate/migrate-data-between-elasticsearch-clusters-with-minimal-downtime.md +++ b/manage-data/migrate/migrate-data-between-elasticsearch-clusters-with-minimal-downtime.md @@ -52,7 +52,7 @@ Tp complete the migration with minimal downtime, use incremental snapshots. Whil 4. **10:15**: Perform the final cutover. 1. In the old cluster, pause indexing or set indices to read-only. For details on setting indices to read-only to safely pause indexing during migration, check [Index lifecycle actions: Read-only](elasticsearch://reference/elasticsearch/index-lifecycle-actions/ilm-readonly.md). 2. Take a final snapshot. - 3. Restore the snapshot to the new cluster. Again, remember that, to restore indices that already exist, they need to be closed. + 3. Restore the snapshot to the new cluster. Again, remember that to restore indices that already exist, they first need to be closed. 4. Change ingestion and querying to the new cluster. 5. Open the indices in the new cluster.