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 de41b40
Browse filesBrowse the repository at this point in the historyBrowse files
Copy file name to clipboardExpand all lines: ChangeLog.md
+5Lines changed: 5 additions & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -7,6 +7,11 @@ BUG FIXES
7
7
-`list` and `tables` text output is now written to stdout as a single write, so a log line on stderr can no longer land in the middle of a backup row when both streams are merged (`docker exec`, `2>&1`), the same fix `json` / `yaml` / `csv` / `tsv` formats got in v2.8.1
8
8
- `restore` / `restore_remote` with `--restore-database-mapping` / `--restore-table-mapping` of tables on object disks (`s3`, `azure_blob_storage`, including `cache` and `encrypted` wrappers) no longer leaves the restored copy sharing object storage keys with the source table, so `DROP TABLE|DATABASE ... SYNC` of the copy no longer deletes the objects of the source (`Code: 499 ... The specified key does not exist (S3_ERROR)` on the source afterwards): the key rewrite was skipped when the disk endpoint key prefix contained the backup name (e.g. backup `regression` on the disk `https://s3/bucket/regression-test/live/`), and the metadata files were linked into `detached` / the table directory before the keys were rewritten, so an interrupted restore left the copy pointing to the source keys; the rewritten key now also carries a hash of the destination table (`<dir>_<backup_name>_<crc32(db.table)>/<object>`), so several copies of one backup restored next to each other never share objects, the source key of the copy is always derived from the backup, so the same local backup can be restored several times, and metadata files are written via temp file + rename, so a repeated restore never modifies the parts of an already restored table through their shared hardlink, fix [#1568](https://github.com/Altinity/clickhouse-backup/issues/1568)
9
9
-`upload --resume` no longer writes an incomplete `manifest.bolt.gz`: files of parts, archives and table metadata which the resumable state marks as already processed were skipped without being recorded in the manifest, so the manifest of a resumed upload listed only the files of the last attempt, overwrote the fuller one and `download` / `restore_remote` fell back to a `Walk` (ListObjectsV2) per skipped part. Skipped files are now recorded from the local backup without any extra remote listing; with `--delete-source` (`create_remote`) the local part files are already removed, so parts skipped on resume stay out of the manifest and still use the `Walk` fallback, fix [#1569](https://github.com/Altinity/clickhouse-backup/issues/1569)
10
+
- SFTP `upload` of compressed archives (`compression_format` other than `none`) now keeps `sftp.concurrency` writes in flight per file, previously the archive stream from the compressor has no known size, so every 32KiB write waited for the previous one (about 8MB/s per file at 4ms RTT), fix [#1607](https://github.com/Altinity/clickhouse-backup/issues/1607)
11
+
- SFTP `download` with `download_max_bytes_per_second` now keeps concurrent reads per file, the rate limiter wrapper hid `WriteTo` of the SFTP file, so every 32KiB read waited for the previous one and the download stayed at about 75% of the limit, fix [#1607](https://github.com/Altinity/clickhouse-backup/issues/1607)
12
+
- GCS ranged download (`gcs.ranged_download_concurrency`) with `download_max_bytes_per_second` now reaches the limit instead of about 80% of it, the limit is applied to each range request on the wire instead of the in-order consumer, which waited idle until the first chunks arrived and never made up the lost time, fix [#1607](https://github.com/Altinity/clickhouse-backup/issues/1607)
13
+
- change default `gcs.ranged_download_min_size` from 256MiB to 64MiB, with `gcs.ranged_download_concurrency` enabled archives of 64-256MiB, typical for big parts, were downloaded by a single stream and stayed the tail of the download, fix [#1607](https://github.com/Altinity/clickhouse-backup/issues/1607)
14
+
- GCS with `force_http: true` or `disable_http2: true` no longer opens a new TCP connection for most requests, the HTTP/1.1 transport kept only 1 (64 with `disable_http2`) idle connection, so a download with many concurrent transfers left closed connections in TIME_WAIT, exhausted the ephemeral port range and failed with `connect: cannot assign requested address`, fix [#1607](https://github.com/Altinity/clickhouse-backup/issues/1607)
Copy file name to clipboardExpand all lines: ReadMe.md
+1-1Lines changed: 1 addition & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -449,7 +449,7 @@ gcs:
449
449
# GCS_RANGED_DOWNLOAD_CONCURRENCY, stream one large archive as N concurrent byte-range requests straight into decompression, without a temporary file and compatible with `download_max_bytes_per_second`,
450
450
# one GCS read stream has a fixed ceiling, so a single big part is often the whole tail of a download, 0 or 1 disables, takes precedence over `allow_multipart_download` for archives >= `ranged_download_min_size`, see https://github.com/Altinity/clickhouse-backup/issues/1592
451
451
ranged_download_concurrency: 0
452
-
ranged_download_min_size: 268435456# GCS_RANGED_DOWNLOAD_MIN_SIZE, archives smaller than this size in bytes keep the single-stream reader, at least 2 * `ranged_download_chunk_size`
452
+
ranged_download_min_size: 67108864# GCS_RANGED_DOWNLOAD_MIN_SIZE, archives smaller than this size in bytes keep the single-stream reader, at least 2 * `ranged_download_chunk_size`
453
453
ranged_download_chunk_size: 33554432# GCS_RANGED_DOWNLOAD_CHUNK_SIZE, bytes per range request, one chunk is one in-memory buffer
454
454
ranged_download_max_buffers: 64# GCS_RANGED_DOWNLOAD_MAX_BUFFERS, process-wide limit of chunk buffers in flight for all ranged readers, so extra memory is at most `ranged_download_max_buffers` * `ranged_download_chunk_size` (2GiB by default) however many archives are in flight
455
455
# GCS_OBJECT_LABELS, allow setup metadata for each object during upload, use {macro_name} from system.macros and {backupName} for current backup name
require.True(t, remote.used.Load(), "ranged reader was not used")
246
+
require.NotNil(t, remote.limiter, "the rate limit must be applied to the range requests, see https://github.com/Altinity/clickhouse-backup/issues/1607")
0 commit comments