Skip to content

Make pg_basebackup work with encrypted WAL #473

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Draft
wants to merge 5 commits into
base: TDE_REL_17_STABLE
Choose a base branch
from

Conversation

dAdAbird
Copy link
Member

@dAdAbird dAdAbird commented Jul 17, 2025

WIP, needs TAP tests

{
#ifdef PERCONA_EXT
/*
* Don't rewrite WAL keys and providers. User may have different
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think this is a good idea: this also skips the providers file, which contains the global providers.
Global providers are also used without wal encryption, so in this regard, this is a breaking change.

Also, this can result in the server unable to start up, if it tries to do recovery on an encrypted table, as it can't load the keys.

If we only skip the keys file, startup after backup seems to work consistently.

dAdAbird added 4 commits July 28, 2025 16:31
When WAL is streamed during the backup (default mode), it comes in
unencrypted. But we need keys to encrypt it. For now, we expect that
the user would put `pg_tde` dir containing the `1664_key` and
`1664_providers` into the destination directory before starting the
backup. And we encrypt streamed WAL according to the internal keys. No
`pg_tde` dir means no streamed WAL encryption.
As it may clash with encrypted WAL streaming.

Hide the fetch option from the usage output and throw an error if it is used.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants