Epic: tenant relocation between pageserver nodes

[kelvich]

Motivation

We want to be able to assign tenants and timelines to the pageserver running on the appropriate EC2 instances, to be able to distribute the tenants and their workloads on EC2 instances fairly. This helps achieve the stable user query latencies, avoid noisy neighbor issues and when necessary perform maintenance and upgrades on the nodes where the pageserver runs.

See #985 for a similar issue on safekeepers

DoD

Add possibility to move tenant from one storage node to another. For now it is okay to require compute node restart to do that.

There should be a button in control plane to trigger the migration. Aside from compute restart there shouldnt be any downtime.

Tasks

For more in-depth description see the last RFC on the topic: #3868

For actual progress see the project board: https://github.com/orgs/neondatabase/projects/27/views/2

As described in the RFC we implement simpler approach first. The downside is the short downtime. The approach can evolve into one without the downtime after we solve immediate tech debt issues.

• Report attach failures in pageserver API #4344

[LizardWizzard]

Some more notes.

What is the sequence of actions to test moving a tenant to a different pageserver?

1. Init pageserver old
2. Create new tenant
3. Insert some data
4. Run a checkpoint
5. Wait for it to be uploaded to the remote storage
6. Bootstrap new pageserver
7. Wait for all the data to be downloaded
8. Execute callmemaybe so new pageserver starts replication from safekeeper
9. Wait for replication to catch up
10. Restart compute with changed pageserver address
11. Shut down tenant on the old pageserver

What bothers me the most is that it becomes possible for two pageservers to write checkpoints concurrently to the same s3 path. Though they'll probably write the same data I wouldnt rely on that, there might be a version upgrade and the format might diverge. So I think we shouldn't allow that. This case can be guarded with some flags like when we attach timeline to a different pageserver it shouldn't try to upload something to s3. But this is still quite tricky. We shouldn't crash because of OOM here because InMemoryLayers can now be swapped to disk but still we should manage this somehow. I'll investigate possible solutions

[kelvich]

Some more notes.

What is the sequence of actions to test moving a tenant to a different pageserver?

1. Init pageserver old

2. Create new tenant

3. Insert some data

4. Run a checkpoint

5. Wait for it to be uploaded to the remote storage

6. Bootstrap new pageserver

7. Wait for all the data to be downloaded

8. Execute callmemaybe so new pageserver starts replication from safekeeper

9. Wait for replication to catch up

10. Restart compute with changed pageserver address

11. Shut down tenant on the old pageserver

I think for a v0 you can just go from 7 to 10 directly. It would be a bigger performance hiccup for compute, but should be okay from the correctness standpoint. After that we can add more synchronization between steps 7-10. Note that you can connect pageserver to safekeeper without callmemaybe.

What bothers me the most is that it becomes possible for two pageservers to write checkpoints concurrently to the same s3 path. Though they'll probably write the same data I wouldnt rely on that, there might be a version upgrade and the format might diverge. So I think we shouldn't allow that. This case can be guarded with some flags like when we attach timeline to a different pageserver it shouldn't try to upload something to s3. But this is still quite tricky. We shouldn't crash because of OOM here because InMemoryLayers can now be swapped to disk but still we should manage this somehow.

OOM shouldn't be the case here since pageserver anyway can spill files to disk. We can have unconditional check that if we are trying to overwrite existing valid files on s3 we need to check crc/hashsum and do nothing if they match -- that should help with your case IIUC.

[LizardWizzard]

I think for a v0 you can just go from 7 to 10 directly

Yeah, currently I just insert sleep calls if something needs waiting with todos to replace with api calls for proper synchronization.

do nothing if they match

What if they don't? Currently there is an archiving mechanism on the way to land in #874 and I've raised similar concerns there too. Can there be some non determinism in the files layout? Can there be a different version of pageserver with some changes to file layout? So I think now we might want to avoid both: overwriting files in s3, extracting s3 data to non empty local timeline we do not download anything for timeline that is available locally. Though it is good to check for race conditions etc. What do you think?

I've created #971 so maybe it is better to continue discussion there

cc @SomeoneToIgnore

[LizardWizzard]

Let me summarize whats left here:

• There is a possible race with branch creation. So if branch is created when relocation is in progress it can be lost. There is a possible fix to track that on the client side. I e make some eventually consistent algorithm which will converge to proper branch set on target pageserver. This solution was implemented but was not committed to cloud repo.

• Other issue is related to background operations that can corrupt state on remote storage (s3) if they're running on both pageservers simultaneously (gc/compaction)

This can be mitigated by suspending background operations before relocation. Corresponding issue: #2740 I attempted to implement that, but with current state of tenant management thing its hard to do that reliably. PR with that attempt #2665

This approach has some downsides, and I wrote an RFC with better proposal, but it is a way heavier change: #2676. RFC involves some future problems which will occur when we start thinking about scaling one tenant to multiple pageservers

So I think its better to start with suspending background operations now

[LizardWizzard]

Another bug that needs to be resolved: #3478

[jcsp]

This ticket is quite old, and described an earlier migration approach with downtime, that already exists. Closing in favour of #5199 for the ongoing work to enable seamless migration.