extremely slow schema updates after MUPdate
Nobody has claimed this yet.
Assessment
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Newbie friendliness
- 35/100
Research direction
Start with the Nexus logs and the DTrace query output to trace the slow schema migration, then compare them with the CockroachDB jobs table and logs. Determine why the migration makes forward progress so slowly after an R18-to-R19 MUPdate and verify that Nexus completes the schema update without appearing unavailable before opening its listening sockets.
Written by the indexing model from the issue text.
Description
On a customer system, after a MUPdate, we found that the normal schema migration that Nexus does was proceeding very slowly. In fact, we initially thought Nexus hadn't come up because:
$ omdb nexus update-status
note: Nexus URL not specified. Will pick one from DNS.
note: using DNS from system config (typically /etc/resolv.conf)
note: (if this is not right, use --dns-server to specify an alternate DNS server)
warning: failed to connect to NexusLockstep at ...:12232: connect "...:12232": Connection refused (os error 146)
warning: failed to connect to NexusLockstep at ...:12232: connect "...:12232": Connection refused (os error 146)
warning: failed to connect to NexusLockstep at ...:12232: connect "...:12232": Connection refused (os error 146)
Error: failed to connect to any instances of NexusLockstep
We looked at it for a while before realizing that Nexus was making forward progress, just very slowly. Nexus completes schema migrations before opening up its listening sockets, which is why we got the error above.
For reference:
- I believe this was a MUPdate from R18 to R19.
- The rack was parked for MUPdate around 2026-04-30T16:00:00Z, or 9am PT.
We were able to tell that schema upgrade steps were happening very slowly but it wasn't clear why. We looked at various data:
- Nexus logs
- output from a DTrace script showing queries executing by Nexus nodes
- the jobs table reported by CockroachDB
- CockroachDB logs
More details coming.
- Dominant language
- Rust
- Stars
- 572
- Forks
- 97
- Avg merge
- 2d 12h
- Merged PRs (30d)
- 96
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from oxidecomputer/omicron
-
Difficulty 1/5 Under an hour Newbie friendliness 88/100
oxidecomputer/omicron#11269 ·
-
Difficulty 1/5 Under an hour Newbie friendliness 92/100
oxidecomputer/omicron#11266 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
oxidecomputer/omicron#11260 · 1 comment ·
-
wicket's errors should be better when trying to read sensitive data from ssh without a pseudo-tty Open
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
oxidecomputer/omicron#11148 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
oxidecomputer/omicron#10907 ·
All issues in oxidecomputer/omicron
Similar issues
-
Difficulty 2/5 1-3 hours Newbie friendliness 86/100
kwakseongjae/auto-hwp#319 ·
-
area:cli bug filter-quality good first issue priority:medium
Difficulty 2/5 1-3 hours Newbie friendliness 84/100
-
Difficulty 1/5 Under an hour Newbie friendliness 72/100
bevyengine/bevy#25861 ·
-
comp-datalake
Difficulty 2/5 1-3 hours Newbie friendliness 88/100
ClickHouse/ClickHouse#121222 ·
-
enhancement remote
Difficulty 2/5 1-3 hours Newbie friendliness 68/100