You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Commit e2afb88
Browse filesBrowse the repository at this point in the historyBrowse files
Copy file name to clipboardExpand all lines: ChangeLog.md
+1Lines changed: 1 addition & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -7,6 +7,7 @@ NEW FEATURES
7
7
BUG FIXES
8
8
- the SQL query log no longer prints passwords embedded in URLs: `pass=` / `password=` query string parameters and `user:password@` are written as `[MASKED]`, with `api.create_integration_tables: true` and `api.password` set every `server` start logged the DDL of `system.backup_actions`, `system.backup_list` and `system.backup_version` with the API password in plain text inside the `URL()` engine argument, at `info` level with the default `clickhouse.log_sql_queries: true`, the query sent to ClickHouse is unchanged, fix [#1630](https://github.com/Altinity/clickhouse-backup/issues/1630)
9
9
-`s3.chunk_size` is now also used when `ceil(file size / chunk_size)` is exactly `s3.max_parts_count`, previously it fell back to `file size / max_parts_count`, ReadMe.md now shows the real default `5242880` and the semantics of `s3.chunk_size`, raise it to upload big files as fewer bigger parts instead of `max_parts_count=1` workaround, each multipart upload allocates about `(s3.concurrency + 2) * chunk_size` bytes, `s3.chunk_size` and `azblob.chunk_size` also apply to uploads into object disks during restore, fix [#1142](https://github.com/Altinity/clickhouse-backup/issues/1142)
10
+
- `watch --env=KEY=VALUE` and `server --env=KEY=VALUE` no longer lose the `--env` overrides, config reload on every `watch` iteration (also inside `server --watch` and `POST /backup/watch`) read only the config file and the real environment, so e.g. `--env=REMOTE_STORAGE=ftp` turned back into the config file value and backups went to the wrong remote storage, and `server` never applied its `--env` to its own config at all (startup, `POST /restart`, `SIGHUP` and every API handler reload); `--env` is now applied to the process environment once at startup and kept for the whole process lifetime, so `/backup/actions` commands and operations resumed after restart (`api.complete_resumable_after_restart`) inherit the `server --env` too, `--env` passed inside a `/backup/actions` command still wins and is restored after the command; a duplicated `--env` key keeps the last value; `server` now exits on an invalid config (including a bad `--env` value) instead of retrying every 5 seconds forever, only the ClickHouse connection is still awaited; `general.disable_environment_override: true` still ignores `--env`
10
11
- `--resume` (and `use_resumable_state: true`) now starts from scratch when the config which defines where the resumable state keys point to changed since the interrupted run: `remote_storage`, the active storage location (`s3` endpoint/bucket/path, `gcs` endpoint/bucket/path, `azblob` endpoint_suffix/account_name/container/path, `cos` url/path, `ftp` address/path, `sftp` address/port/path; `path` is not used by `create`), `object_disk_path`, the customer-provided encryption key (`s3.sse_customer_key`, `gcs.encryption_key`, `azblob.sse_key`, only its digest is stored), `compression_format` for `upload` / `create_remote`, and `restore_database_mapping` / `restore_table_mapping` for `restore` / `restore_remote --streaming`; the state keys are relative to the storage path, so `upload --resume` after changing `s3.path` used to skip every file already uploaded to the old path; tuning concurrency, retries, credentials or `log_level` still keeps the resume; the discarded state is logged as a warning with the changed parameters only; `ResumeOperationsAfterRestart` now passes `--restore-database-mapping` / `--restore-table-mapping` back to the resumed `restore` / `restore_remote --streaming`. **Upgrade note**: resumable states written by previous versions have no config fingerprint and are discarded on the first `--resume` after upgrading, so an interrupted operation restarts from scratch once, fix [#1010](https://github.com/Altinity/clickhouse-backup/issues/1010)
11
12
- `watch` no longer treats a failed `backups_to_keep_remote` / `backups_to_keep_local` retention or `--delete-source` after a completely uploaded backup as a failed upload: the new backup becomes the base of the next increment (previously the next increment was diffed from a stale base) and the failure is not counted towards `too many errors ... abort watching`, so a permanently failing post-upload step no longer stops `watch`, it is reported only by the error log, `/backup/status`, `system.backup_actions` and the callback, with `api.enable_metrics` the `failed_create_remotes` counter keeps growing and `last_create_remote_status` stays `0` while new backups are uploaded; all post-upload steps now run even when a previous one failed and their errors are reported together; with `--schedule` the `full_type: rebase` and `delete_previous_cycle` steps also proceed, a failed rebase is reported together with the post-upload error and the backup is not used as the base; `use_embedded_backup_restore_cluster` initiator waits for the worker nodes before the backup is used as the base, a post-upload failure on a worker node is still counted as a failed upload; `create_remote --streaming` no longer reports such a complete backup as partial; one-shot `create_remote` and `upload` still exit with a non-zero code, fix [#1535](https://github.com/Altinity/clickhouse-backup/issues/1535)
12
13
- `restore --schema --rm` without `restore_schema_on_cluster` on a replica of `ENGINE=Replicated` database, when the database schema was already restored from another replica (ACM restore sequence and `How to back up / restore a sharded cluster` in Examples.md), no longer fails with `code: 529 ... Cannot enqueue query on this replica, because it has replication lag`, `code: 36 ... It's not allowed to specify explicit zookeeper_path and replica_name` or `Table ... already exists`: local `DROP DATABASE` of a Replicated database is skipped (it removed only the current replica, which then recovered from the database DDL log concurrently with the following DROP/CREATE TABLE, tables are still dropped and their DROP TABLE is replicated), `SYSTEM SYNC DATABASE REPLICA` is executed before and after dropping tables (ClickHouse 22.5+), and `{uuid}` macro of `Replicated*MergeTree` path is no longer replaced with the backup table UUID and the replication path is no longer rebound to `default_replica_path` inside a Replicated database, fix [#1611](https://github.com/Altinity/clickhouse-backup/issues/1611)
0 commit comments