patroni.postgresql.bootstrap module

class patroni.postgresql.bootstrap.Bootstrap(postgresql: Postgresql)View on GitHub

Bases: object

__init__(postgresql: Postgresql) → NoneView on GitHub
_custom_bootstrap(config: Any) → boolView on GitHub

Bootstrap a fresh Patroni cluster using a custom method provided by the user.

Parameters:

config – configuration used for running a custom bootstrap method. It comes from the Patroni YAML file, so it is expected to be a dict.

Note

config must contain a command key, which value is the command or script to perform the custom bootstrap procedure. The exit code of the command dictates if the bootstrap succeeded or failed.

When calling command, Patroni will pass the following arguments to the command call:

  • --scope: contains the value of scope configuration;

  • --data_dir: contains the value of the postgresql.data_dir configuration.

You can avoid that behavior by filling the optional key no_params with the value False in the configuration file, which will instruct Patroni to not pass these parameters to the command call.

Besides that, a couple more keys are supported in config, but optional:

  • keep_existing_recovery_conf: if True, instruct Patroni to not remove the existing recovery.conf (PostgreSQL <= 11), to not discard recovery parameters from the configuration (PostgreSQL >= 12), and to not remove the files recovery.signal or standby.signal (PostgreSQL >= 12). This is specially useful when you are restoring backups through tools like pgBackRest and Barman, in which case they generated the appropriate recovery settings for you;

  • recovery_conf: a section containing a map, where each key is the name of a recovery related setting, and the value is the value of the corresponding setting.

Any key/value other than the ones that were described above will be interpreted as additional arguments for the command call. They will all be added to the call in the format --key=value.

Returns:

True if the bootstrap was successful, i.e. the execution of the custom command from config exited with code 0, False otherwise.

_initdb(config: Any) → boolView on GitHub
_post_restore() → NoneView on GitHub
basebackup(conn_url: str, env: Dict[str, str], options: Dict[str, Any]) → int | NoneView on GitHub
bootstrap(config: Dict[str, Any]) → boolView on GitHub

Initialize a new node from scratch and start it.

call_post_bootstrap(config: Dict[str, Any]) → boolView on GitHub

runs a script after initdb or custom bootstrap script is called and waits until completion.

clone(clone_member: Leader | Member | None) → boolView on GitHub

  • initialize the replica from an existing member (primary or replica)

  • initialize the replica using the replica creation method that works without the replication connection (i.e. restore from on-disk base backup)

create_or_update_role(name: str, password: str | None, options: List[str]) → NoneView on GitHub
create_replica(clone_member: Leader | Member | None) → int | NoneView on GitHub

create the replica according to the replica_method defined by the user. this is a list, so we need to loop through all methods the user supplies

property keep_existing_recovery_conf: bool
post_bootstrap(config: Dict[str, Any], task: CriticalTask) → bool | NoneView on GitHub
static process_user_options(tool: str, options: Any | Dict[str, str] | List[str | Dict[str, Any]], not_allowed_options: Tuple[str, ...], error_handler: Callable[[str], None]) → List[str]View on GitHub

Format options in a list or dictionary format into command line long form arguments.

Note

The format of the output of this method is to prepare arguments for use in the initdb method of self._postgres.

Example:

The options can be defined as a dictionary of key, values to be converted into arguments: >>> Bootstrap.process_user_options(‘foo’, {‘foo’: ‘bar’}, (), print) [’–foo=bar’]

Or as a list of single string arguments >>> Bootstrap.process_user_options(‘foo’, [‘yes’], (), print) [’–yes’]

Or as a list of key, value options >>> Bootstrap.process_user_options(‘foo’, [{‘foo’: ‘bar’}], (), print) [’–foo=bar’]

Or a combination of single and key, values >>> Bootstrap.process_user_options(‘foo’, [‘yes’, {‘foo’: ‘bar’}], (), print) [’–yes’, ‘–foo=bar’]

Options that contain spaces are passed as is to subprocess.call >>> Bootstrap.process_user_options(‘foo’, [{‘foo’: ‘bar baz’}], (), print) [’–foo=bar baz’]

Options that are quoted will be unquoted, so the quotes aren’t interpreted literally by the postgres command >>> Bootstrap.process_user_options(‘foo’, [{‘foo’: ‘“bar baz”’}], (), print) [’–foo=bar baz’]

Note

The error_handler is called when any of these conditions are met:

  • Key, value dictionaries in the list form contains multiple keys.

  • If a key is listed in not_allowed_options.

  • If the options list is not in the required structure.

Parameters:

  • tool – The name of the tool used in error reports to error_handler

  • options – Options to parse as a list of key, values or single values, or a dictionary

  • not_allowed_options – List of keys that cannot be used in the list of key, value formatted options

  • error_handler – A function which will be called when an error condition is encountered

Returns:

List of long form arguments to pass to the named tool

property running_custom_bootstrap: bool