Delete docs/rpc/run-rpc-node-without-nearup.md #130
Conversation
This file contains hidden or 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
bucanero
temporarily deployed
to
walnut-the-cat-patch-1 - node-docs PR #130
Render
Destroyed
bucanero
temporarily deployed
to
walnut-the-cat-patch-1 - node-docs PR #130
Render
Destroyed
bucanero
temporarily deployed
to
walnut-the-cat-patch-1 - node-docs PR #130
Render
Destroyed
bucanero
temporarily deployed
to
walnut-the-cat-patch-1 - node-docs PR #130
Render
Destroyed
VanBarbascu
reviewed
Sep 22, 2025
|
|
||
| With the 1.35.0 release we are rolling out split storage, a new option for storage management that is mainly targeted at archival nodes.. Split storage allows nodes to reduce storage costs and improve block production performance by splitting local storage into two separate areas: a hot and a cold database . The hot database is smaller in size and stores all of the data from the most recent epochs. The cold database is larger, and it stores all historical data for older epochs. Hot and cold databases can be independently placed on separate hardware storage, allowing configurations such as using hot storage on a fast NVMe drive, and placing cold storage on a cheaper HDD drive. | ||
|
|
||
| In split storage mode, the Near Client only works with a smaller hot database to produce blocks, which results in increased performance. Cold database is not accessed for reads during normal block production and is only read when historical data is specifically requested. Thus, we recommend keeping the cold database on cheaper and slower drives such as an HDD and only optimize speed for the hot database, which is about 10 times smaller. |
There was a problem hiding this comment.
Suggested change
| In split storage mode, the Near Client only works with a smaller hot database to produce blocks, which results in increased performance. Cold database is not accessed for reads during normal block production and is only read when historical data is specifically requested. Thus, we recommend keeping the cold database on cheaper and slower drives such as an HDD and only optimize speed for the hot database, which is about 10 times smaller. | |
| In split storage mode, the Near Client only works with a smaller hot database to produce blocks, which results in increased performance. Cold database is not accessed for reads during normal block production and is only read when historical data is specifically requested. Thus, we recommend keeping the cold database on cheaper and slower drives such as an HDD and only optimize speed for the hot database, which is significantly smaller. |
|
|
||
| In split storage mode, the Near Client only works with a smaller hot database to produce blocks, which results in increased performance. Cold database is not accessed for reads during normal block production and is only read when historical data is specifically requested. Thus, we recommend keeping the cold database on cheaper and slower drives such as an HDD and only optimize speed for the hot database, which is about 10 times smaller. | ||
|
|
||
| Split storage is disabled by default, and can be enabled with a config change and going through a migration process that requires manual steps. We have several choices for the migration: |
There was a problem hiding this comment.
IIUC, this section is about migrating from Legacy Archival (one disk), to split archival node. In this case, it is obsolete and can be removed.
| FASTNEAR is now provider of Archival node snapshot. Please refer to their documentation [HERE](https://docs.fastnear.com/docs/snapshots/mainnet#archival-mainnet-snapshot) | ||
|
|
||
| ### If your node is out of sync after restarting from the latest snapshot {#syncing node} | ||
| Downloading the cold database can take a long time (days). In this time your database can become very far behind the chain. |
There was a problem hiding this comment.
From my understanding of the Archival implementation. This is not supported as it will generate gaps in the archival data if you put an RPC db with tail greater then the cold head.
There was a problem hiding this comment.
Agree, this procedure creates more problems than it solves
wacban
approved these changes
Sep 23, 2025
| ``` | ||
|
|
||
| ## Using Pagoda-provided S3/CloudFrontsplit-storage snapshots {#S3 migration} | ||
| ## Using Snaphots {#S3 migration} |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
5 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
No description provided.