Skip to content

Commit f3e57dc

Browse files
authored
Merge pull request #12 from Dockermint/docs/pebbledb-guide
docs(guides): add pebbledb build guide under docs/guides
2 parents f1946a6 + 09b3eaf commit f3e57dc

1 file changed

Lines changed: 168 additions & 0 deletions

File tree

docs/guides/build_with_pebbledb.md

Lines changed: 168 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,168 @@
1+
# Build with PebbleDB
2+
3+
This guide explains how a Cosmos SDK chain gains PebbleDB support: when it is
4+
available natively, how to patch older chains that do not support it out of the
5+
box, and how to enable it at build time. It targets two audiences:
6+
7+
- **Node operators** who want to understand what Dockermint does under the
8+
hood when they select the `db_backend = "pebbledb"` flavour in a recipe.
9+
- **Dockermint contributors** working on the `builder` module or on new
10+
recipes that need to expose PebbleDB as a flavour.
11+
12+
## 1. Native support
13+
14+
PebbleDB is supported natively starting with
15+
`github.com/cometbft/cometbft-db` **v0.10.0**.
16+
17+
In practice, this corresponds to chains built on top of:
18+
19+
- CometBFT **v0.38.0** or newer, and
20+
- Cosmos SDK **v0.50** or newer.
21+
22+
Any chain whose `go.mod` already pins `cometbft-db >= v0.10.0` can be compiled
23+
with PebbleDB without any source-level patching: only the appropriate build
24+
tags and `ldflags` are required (see section 3).
25+
26+
Any chain pinning an older version of `cometbft-db`, or still relying on the
27+
legacy `github.com/tendermint/tm-db`, does **not** support PebbleDB natively
28+
and must be patched before compilation (see section 2).
29+
30+
## 2. Patching older chains
31+
32+
For chains that predate `cometbft-db v0.10.0`, PebbleDB support is available
33+
through community-maintained forks published by `notional-labs`. These forks
34+
are drop-in replacements, injected via `go mod edit -replace`.
35+
36+
Run the following commands from the chain's Go module root (the directory
37+
containing `go.mod`) **before** running `go build`:
38+
39+
```bash
40+
# Always required for chains below cometbft-db v0.10.0
41+
go mod edit -replace \
42+
github.com/cometbft/cometbft-db=github.com/notional-labs/cometbft-db@pebble
43+
44+
# Required only if the chain still imports the legacy tm-db
45+
go mod edit -replace \
46+
github.com/tendermint/tm-db=github.com/notional-labs/tm-db@v0.6.8-pebble
47+
48+
# Required only if the chain imports github.com/cosmos/cosmos-db
49+
go mod edit -replace \
50+
github.com/cosmos/cosmos-db=github.com/notional-labs/cosmos-db@pebble
51+
52+
# Resolve the new dependency graph
53+
go mod tidy
54+
```
55+
56+
Notes:
57+
58+
- The three `replace` directives are independent. Apply only the ones that
59+
match modules actually imported by the chain. A quick check:
60+
61+
```bash
62+
grep -E 'cometbft-db|tm-db|cosmos-db' go.mod
63+
```
64+
65+
- The `@pebble` and `@v0.6.8-pebble` identifiers are the branches and tags
66+
maintained by `notional-labs` that carry the PebbleDB backend.
67+
- If a specific revision is required (for reproducibility or to pick up a
68+
fix), replace `@pebble` with an explicit commit hash or tag, for example
69+
`@v0.11.0-pebble-1`.
70+
- Expect some trial and error. The `notional-labs` forks are community
71+
maintained and ship several branches and tags that are not always mutually
72+
compatible with every chain version. If `go mod tidy` or the build fails
73+
with resolution or API errors, try another tag (for example swap `@pebble`
74+
for `@v0.11.0-pebble-1`, `@v0.9.1-pebble`, or a specific commit hash) until
75+
a combination compiles cleanly against the target chain.
76+
- All of these forks live under the `notional-labs` GitHub organization at
77+
<https://github.com/notional-labs>. Browse the repositories directly to
78+
discover the available branches and tags for each module.
79+
80+
Once the `replace` directives are in place and `go mod tidy` has succeeded,
81+
the chain can be compiled exactly as a natively-supported chain.
82+
83+
## 3. Enabling PebbleDB at build time
84+
85+
PebbleDB is gated behind a build tag. It must be enabled explicitly by
86+
passing both a build tag and an `ldflag` to `go build`:
87+
88+
```bash
89+
go build \
90+
-tags 'ledger,pebbledb' \
91+
-ldflags "-X github.com/cosmos/cosmos-sdk/types.DBBackend=pebbledb" \
92+
-o /path/to/output/binary \
93+
./cmd/<chain-daemon>
94+
```
95+
96+
What each flag does:
97+
98+
- `-tags 'ledger,pebbledb'` compiles the PebbleDB code path into the
99+
binary. The `ledger` tag is kept to preserve hardware wallet support; add
100+
any other tags the chain normally requires.
101+
- `-ldflags "-X github.com/cosmos/cosmos-sdk/types.DBBackend=pebbledb"` sets
102+
PebbleDB as the default backend baked into the binary, so a freshly
103+
initialised node uses PebbleDB without any additional configuration.
104+
105+
A more complete invocation, mirroring what is typically wanted for a release
106+
build, looks like:
107+
108+
```bash
109+
go build \
110+
-mod=readonly \
111+
-trimpath \
112+
-tags 'ledger,pebbledb' \
113+
-ldflags "\
114+
-X github.com/cosmos/cosmos-sdk/version.Name=<chain-name> \
115+
-X github.com/cosmos/cosmos-sdk/version.AppName=<daemon-name> \
116+
-X github.com/cosmos/cosmos-sdk/version.Version=<git-tag> \
117+
-X github.com/cosmos/cosmos-sdk/version.Commit=<git-commit> \
118+
-X 'github.com/cosmos/cosmos-sdk/version.BuildTags=ledger,pebbledb' \
119+
-X github.com/cosmos/cosmos-sdk/types.DBBackend=pebbledb" \
120+
-o /usr/local/bin/<daemon-name> \
121+
./cmd/<daemon-name>
122+
```
123+
124+
After installing the resulting binary, confirm that PebbleDB is compiled in:
125+
126+
```bash
127+
<daemon-name> version --long | grep -i build_tags
128+
```
129+
130+
The output should contain `ledger,pebbledb`. Existing nodes that are
131+
switching from `goleveldb` must also update their `config.toml`
132+
(`db_backend = "pebbledb"`) and either re-sync, import a PebbleDB snapshot,
133+
or convert an existing `goleveldb` database with
134+
[Pebblify](https://github.com/Dockermint/pebblify), since the two backends
135+
are not on-disk compatible.
136+
137+
## 4. Mapping to Dockermint
138+
139+
All the steps above are performed by Dockermint's `builder` module whenever
140+
a recipe exposes `pebbledb` in its `[flavours.available]` section and the
141+
user selects it, either through CLI arguments, `config.toml`, or the recipe
142+
defaults:
143+
144+
```toml
145+
[flavours.available]
146+
db_backend = ["goleveldb", "pebbledb"]
147+
148+
[flavours.default]
149+
db_backend = "goleveldb"
150+
```
151+
152+
At build time, Dockermint resolves the selected `db_backend` flavour,
153+
injects the required `go mod edit -replace` directives for chains that
154+
predate native support, and forwards the `pebbledb` build tag along with the
155+
`-X github.com/cosmos/cosmos-sdk/types.DBBackend=pebbledb` linker variable
156+
through the recipe's `[build.linker.flags]` and `[build.linker.variables]`
157+
tables.
158+
159+
## Summary
160+
161+
1. Native support starts at `cometbft-db v0.10.0`
162+
(CometBFT v0.38 / Cosmos SDK v0.50).
163+
2. Older chains must inject the `notional-labs` forks through
164+
`go mod edit -replace` followed by `go mod tidy`.
165+
3. Enabling the backend is done at build time by adding the `pebbledb` build
166+
tag and setting `types.DBBackend=pebbledb` via `-ldflags`.
167+
4. In Dockermint, all of the above is driven by selecting the `pebbledb`
168+
value of the `db_backend` flavour in a recipe.

0 commit comments

Comments
 (0)