-
Notifications
You must be signed in to change notification settings - Fork 53
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
- Loading branch information
1 parent
ae8826a
commit 4ab3c0b
Showing
2 changed files
with
17 additions
and
7 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
22 changes: 16 additions & 6 deletions
22
...s/indexers/migrate-existing-deployment.md → ..._operators/indexers/migrate-deployment.md
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -1,22 +1,32 @@ | ||
# Migrate an existing deployment to new version | ||
# Migrate an Existing Deployment to New Version | ||
|
||
## Backgrounds | ||
When author of a project published a version, sometimes you may want to migrate your local deployment to that version to avoid the extra time spending of indexing. | ||
This guide will help you to do that. | ||
## Background | ||
|
||
Noted, not all deployments support migration, and for those that do, they only support migrated from specific deployments. | ||
If you tried to migrate from a deployment that does not support migration, the project may fail to start, or you will have the risk of undermining the POI (Proof of Index) of the deployment. | ||
When an author of a project publishes a new version of a SubQuery project, sometimes you may want to migrate your local deployment to the new version to avoid time spend reindexing data from scratch. | ||
|
||
:::warning | ||
|
||
Not all SubQuery project deployments support migration, and for those that do, they may only support migrations from specific deployment IDs or block heights. | ||
|
||
If you tried to migrate from a deployment that does not support migrations, the project may fail to start, or you will have the risk of undermining the POI (Proof of Index) of the deployment. | ||
|
||
**As a result, we strongly suggest that you backup the project deployment data before you attempt to migrate it to a new version.** | ||
::: | ||
|
||
## Steps | ||
|
||
1. Check the deployment instruction that you want to migrate to. Usually the author will provide the details about whether the deployment supports migration and from which deployment it can be migrated. | ||
2. Stop the current deployment from Indexer Admin UI | ||
3. Rename schema in the database to the new schema name. The schema name is the first 15 characters of the deployment id, lower case. e.g `schema_<first 15>` | ||
|
||
``` | ||
# if you runs postgres in docker-compose | ||
sudo docker exec -it indexer_db psql -h localhost -p 5432 -U postgres -d postgres | ||
ALTER SCHEMA <old> RENAME TO <new>; | ||
``` | ||
|
||
4. Add new deployment and start from Indexer Admin UI. | ||
5. Move allocation to the new deployment. | ||
5. Delete old project | ||
|
||
|