Pghoard

Latest version: v2.1.0

Safety actively analyzes 683530 Python packages for vulnerabilities to keep your Python projects secure.

Scan your dependencies

Page 1 of 2

2.1.0

==========================

* Support for passing statistics to Prometheus
* Progress monitoring of basebackups
* Fix incompatibility with legacy PGHoard backups (2.0.0 was unable to
restore backups taken with much older versions)
* Compatibility improvements for different S3 api implementations
* Support for Zstandard (zstd) compression
* Support SFTP file storage
* File storage APIs (rohmu) support streaming

2.0.0

==========================

* Support for PostgreSQL 11
* Drop support for PosgreSQL 9.2
* Multiprocess parallel basebackup restore
* Performance improvements
* Bug fixes
* Python 3.7 compatibility

1.7.0

==========================

* Support for PostgreSQL 10.1+
* Use fast checkpoints by default to make the start of backups faster. Slow
progress at the beginning of the backup has a tendency to confuse people.
* Allow overriding the name of the folder for a site's backups by using a
new site-level configuration option ``prefix``. Previously backups were
always stored in a folder named after the site, optionally prefixed by an
undocumented top-level configuration option ``path_prefix`` which is now
deprecated.
* ``archive_cleanup`` storage errors are no longer fatal (just logged as
errors now). Total WAL segment storage size savings is reported after
cleanup. There is a 'dry run' mode available now to estimate cleanup
effect before deleting actual items.
* Use botocore rather than boto for interfacing with S3. Botocore is the
underlying and maintained library under the newer boto3 SDK.
* Add a new --tablespace-base-dir option to restore so you can put all
the tablespaces under a single directory hierarchy.
* Miscellaneous bug fixes and improvements

1.6.0

==========================

* Support for PostgreSQL 10
* ``local-tar`` backups are now split to roughly 2 gigabyte chunks of
plain-text files. New basebackups now benefit from some parallelization,
as up to 5 chunks may be uploaded in parallel while new backup chunks are
being created.
* ``pghoard_restore`` can now download and extract chunked basebackups using
all CPU cores of the machine assuming that the parallel download mechanism
can deliver it chunks fast enough
* Alternative ``pghoard_postgres_command`` implementation in Go for faster
startup times. The time that the Python implementation takes to start
limits WAL restore throughput quite a bit
* Remove support for ``pg_xlog_directory`` config variable, we now require
``pg_data_directory`` to be set in the config for the backup site. This
is done in order to stop guessing and possibly getting the answer wrong
for the real location of the data.
* Miscellaneous bug fixes

1.5.0

==========================

* New tool, ``pghoard_archive_cleanup`` to clean up any orphan WAL segments
from the object store
* Basebackup ``end-time`` and ``end-wal-segment`` are now stored in metadata and
used for PITR when ``local-tar`` basebackups are used
* Azure object storage updated to work with the latest python-azure-storage
module and promoted to production ready status
* Google object storage driver now retries operations on failure to work
around transient connection reset and backend failure issues
* Google object storage compatibility with Google oauth2client version 1.5+
* S3 driver now supports server side encryption
* Swift driver now supports the region_name configuration option
* Support for ``local-tar`` backups of a replica on PostgreSQL 9.6 and newer
using the new non-exclusive backup mechanism. Previous PostgreSQL
versions require the pgespresso extension to take backups of replicas
using the ``local-tar`` method, the pg_basebackup utilizing (default)
methods have always supported backups of replicas
* When ``local-tar`` basebackups are used in exclusive mode (PG <= 9.5 without
pgespresso) any conflicting exclusive basebackup is automatically cancelled
to allow PGHoard to take its own basebackup. This is sometimes required if
a previous PGHoard process has been killed while it was taking a backup
* Support pghoard_restore --recovery-target-action with 9.3 and 9.4
* Creating a ``maintenance_mode_file`` as documented in README now stops
automatic basebackups from being created
* Changed the default directory for ``maintenance_mode_file`` and
``json_state_file_path`` from ``/tmp`` to ``/var/lib/pghoard``
* Autotune ``compression.thread_count`` and ``transfer_agent.thread_count`` defaults
to be ``max(cpu_count, 5)`` instead of a default of ``5`` as before
* Support for Python 3.6
* Miscellaneous bug fixes

1.4.0

==========================

* Add ability to get state file from webserver using ``GET /status``
* Support for Telegraf and DataDog statsd
* Basebackup restoration now shows download progress
* New ``basebackup_mode`` option: ``local-tar`` to collect files directly from
``$PGDATA`` instead of running pg_basebackup. The ``local-tar`` mode allows
backing up user tablespaces
* New site-specific configuration option ``pg_data_directory`` is required
to use the new ``local-tar`` mode, but it's also recommended in other
configurations as the ``pg_xlog_directory`` option is now deprecated and
will be removed in a future release
* New site-specific configuration option ``pg_bin_directory`` replaces the
previous global ``pg_basebackup_path`` and ``pg_receivexlog_path``
configuration options. This allows handling multiple versions in a single
pghoard configuration and simplifies configuration as a single option is
needed instead of two. Also, if a pg_data_directory exists the binary
directory is automatically looked up from various well-known paths,
removing the requirement of setting this option when using PGDG Debian,
RHEL or Fedora packages.
* Basebackup handling was refactored to more cleanly handle the different
operation modes: pipe data directly from pg_basebackup's stdout to PGHoard
compression or collect the temporary tar files first that pg_basebackup
writes itself. This introduced a new configuration option per site:
``basebackup_mode`` which supersedes the old ``stream_compression`` config
option
* Revamped file transformation (encryption, compression) interfaces
* Make sure object storage modules are importable when reading configuration
instead of only checking it when they are used
* Improved PostgreSQL 9.2, 9.6 beta and Python 3.3 compatibility
* Experimental support for new mode walreceiver which uses the PostgreSQL
replication protocol. Much faster and less resource consuming WAL replication
than when using active_backup_mode: pg_receivexlog.

Page 1 of 2

© 2024 Safety CLI Cybersecurity Inc. All Rights Reserved.