Docs
⌘ K

5 минуты

Развертывание субграфа в нескольких сетях

This page explains how to deploy a Subgraph to multiple networks. To deploy a Subgraph you need to first install the Graph CLI⁠. If you have not created a Subgraph already, see Creating a Subgraph.

Deploying the Subgraph to multiple networks

In some cases, you will want to deploy the same Subgraph to multiple networks without duplicating all of its code. The main challenge that comes with this is that the contract addresses on these networks are different.

Использование graph-cli

Как graph build (начиная с v0.29.0), так и graph deploy (начиная с v0.32.0) допускают две новые опции:

Опции:      ...      --network <name> Конфигурация сети для использования из файла конфигурации сетей      --network-file <path> Путь к файлу конфигурации сетей (по умолчанию: "./networks.json")

You can use the --network option to specify a network configuration from a json standard file (defaults to networks.json) to easily update your Subgraph during development.

Примечание: Команда init теперь автоматически сгенерирует networks.json на основе предоставленной информации. Затем Вы сможете обновить существующие или добавить дополнительные сети.

Если у Вас нет файла networks.json, Вам нужно будет вручную создать его со следующей структурой:

{    "network1": { // the network name        "dataSource1": { // the dataSource name            "address": "0xabc...", // the contract address (optional)            "startBlock": 123456 // the startBlock (optional)        },        "dataSource2": {            "address": "0x123...",            "startBlock": 123444        }    },    "network2": {        "dataSource1": {            "address": "0x987...",            "startBlock": 123        },        "dataSource2": {            "address": "0xxyz..",            "startBlock": 456        }    },    ...}

Примечание: Вам не нужно указывать ни один из templates (если они у Вас есть) в файле конфигурации, только dataSources. Если есть какие-либо templates, объявленные в файле subgraph.yaml, их сеть будет автоматически обновлена до указанной с помощью опции --network.

Now, let’s assume you want to be able to deploy your Subgraph to the mainnet and sepolia networks, and this is your subgraph.yaml:

# ...dataSources:  - kind: ethereum/contract    name: Gravity    network: mainnet    source:      address: '0x123...'      abi: Gravity    mapping:      kind: ethereum/events

Вот как должен выглядеть файл конфигурации ваших сетей:

{  "mainnet": {    "Gravity": {      "address": "0x123..."    }  },  "sepolia": {    "Gravity": {      "address": "0xabc..."    }  }}

Теперь мы можем запустить одну из следующих команд:

# Использование стандартного файла networks.jsonyarn build --network sepolia# Использование файла с пользовательским именемyarn build --network sepolia --network-file path/to/config

The build command will update your subgraph.yaml with the sepolia configuration and then re-compile the Subgraph. Your subgraph.yaml file now should look like this:

# ...dataSources:  - kind: ethereum/contract    name: Gravity    network: sepolia    source:      address: '0xabc...'      abi: Gravity    mapping:      kind: ethereum/events

Теперь Вы готовы выполнить команду yarn deploy.

Примечание: Как упоминалось ранее, начиная с версии graph-cli 0.32.0 Вы можете напрямую выполнить команду yarn deploy с опцией --network:

# Использование стандартного файла networks.jsonyarn deploy --network sepolia# Использование файла с пользовательским именемyarn deploy --network sepolia --network-file path/to/config

Использование шаблона subgraph.yaml

Одним из способов параметризации таких аспектов, как адреса контрактов, с использованием старых версий graph-cli является генерация его частей с помощью системы шаблонов, такой как Mustache⁠ или Handlebars⁠.

To illustrate this approach, let’s assume a Subgraph should be deployed to mainnet and Sepolia using different contract addresses. You could then define two config files providing the addresses for each network:

{  "network": "mainnet",  "address": "0x123..."}

и

{  "network": "sepolia",  "address": "0xabc..."}

Наряду с этим, необходимо заменить имя сети и адреса в манифесте на variable placeholders {{network}} и {{address}} и переименовать манифест, например, subgraph.template.yaml:

# ...dataSources:  - kind: ethereum/contract    name: Gravity    network: mainnet    network: {{network}}    source:      address: '0x2E645469f354BB4F5c8a05B3b30A929361cf77eC'      address: '{{address}}'      abi: Gravity    mapping:      kind: ethereum/events

Чтобы сгенерировать манифест для любой сети, можно добавить две дополнительные команды в package.json вместе с зависимостью от mustache:

{  ...  "scripts": {    ...    "prepare:mainnet": "mustache config/mainnet.json subgraph.template.yaml > subgraph.yaml",    "prepare:sepolia": "mustache config/sepolia.json subgraph.template.yaml > subgraph.yaml"  },  "devDependencies": {    ...    "mustache": "^3.1.0"  }}

To deploy this Subgraph for mainnet or Sepolia you would now simply run one of the two following commands:

# Mainnet:yarn prepare:mainnet && yarn deploy# Sepolia:yarn prepare:sepolia && yarn deploy

Наглядный пример можно найти здесь⁠.

Примечание: Этот подход также можно применять в более сложных ситуациях, когда необходимо заменить не только адреса контрактов и сетевые имена, но и сгенерировать мэппинги или ABI из шаблонов.

This will give you the chainHeadBlock which you can compare with the latestBlock on your Subgraph to check if it is running behind. synced informs if the Subgraph has ever caught up to the chain. health can currently take the values of healthy if no errors occurred, or failed if there was an error which halted the progress of the Subgraph. In this case, you can check the fatalError field for details on this error.

Subgraph Studio Subgraph archive policy

A Subgraph version in Studio is archived if and only if it meets the following criteria:

  • Версия не опубликована в сети (или ожидает публикации)
  • Версия была создана 45 или более дней назад
  • The Subgraph hasn’t been queried in 30 days

In addition, when a new version is deployed, if the Subgraph has not been published, then the N-2 version of the Subgraph is archived.

Every Subgraph affected with this policy has an option to bring the version in question back.

Checking Subgraph health

If a Subgraph syncs successfully, that is a good sign that it will continue to run well forever. However, new triggers on the network might cause your Subgraph to hit an untested error condition or it may start to fall behind due to performance issues or issues with the node operators.

Graph Node exposes a GraphQL endpoint which you can query to check the status of your Subgraph. On the hosted service, it is available at https://api.thegraph.com/index-node/graphql. On a local node, it is available on port 8030/graphql by default. The full schema for this endpoint can be found here⁠. Here is an example query that checks the status of the current version of a Subgraph:

{  indexingStatusForCurrentVersion(subgraphName: "org/subgraph") {    synced    health    fatalError {      message      block {        number        hash      }      handler    }    chains {      chainHeadBlock {        number      }      latestBlock {        number      }    }  }}

This will give you the chainHeadBlock which you can compare with the latestBlock on your Subgraph to check if it is running behind. synced informs if the Subgraph has ever caught up to the chain. health can currently take the values of healthy if no errors occurred, or failed if there was an error which halted the progress of the Subgraph. In this case, you can check the fatalError field for details on this error.