# patroni.postgresql.bootstrap module

class patroni.postgresql.bootstrap.Bootstrap(postgresql: Postgresql)

  Bases: `object`

  __init__(postgresql: Postgresql) → None
  _custom_bootstrap(config: Any) → bool

    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) → bool
  _post_restore() → None
  basebackup(conn_url: str, env: Dict[str, str], options: Dict[str, Any]) → int | None
  bootstrap(config: Dict[str, Any]) → bool

    Initialize a new node from scratch and start it.

  call_post_bootstrap(config: Dict[str, Any]) → bool

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

  clone(clone_member: Leader | Member | None) → bool

    - 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]) → None
  create_replica(clone_member: Leader | Member | None) → int | None

    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 | None
  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]

    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