mirror of
https://github.com/ClickHouse/ClickHouse.git
synced 2024-11-16 20:53:27 +00:00
48 lines
5.0 KiB
Markdown
48 lines
5.0 KiB
Markdown
|
# ClickHouse S3 Zero Copy Replication
|
|||
|
|
|
|||
|
|
Говнокод просто для теста, не production-ready ни разу.
|
|||
|
|
|
|||
|
|
[Коммит](https://github.com/ianton-ru/ClickHouse/commit/acf86568a7e21176ba2cca15861da231bec6932a)
|
|||
|
|
|
|||
|
|
[Ветка](https://github.com/ianton-ru/ClickHouse/tree/s3_zero_copy_replication)
|
|||
|
|
|
|||
|
|
## Как сделано
|
|||
|
|
|
|||
|
|
При fetch-е парта при репликации в случае, если источник хранит, а приемник собирается хранить парт в S3, вместо данных пересылаются только метаданные S3, приемник кладет их локально себе
|
|||
|
|
и испольузет общие с источником данные на S3. Для того, чтобы не удалить такие пошареные данные, делается пометка в ZooKeeper.
|
|||
|
|
|
|||
|
|
Введена новая версия протокола REPLICATION_PROTOCOL_VERSION_WITH_PARTS_S3_COPY. В запросе новый параметр send_s3_metadata, если 1, то приемних просит у источника метаданные вместо данных, если это возможно.
|
|||
|
|
Приемник в ответ отсылает куку send_s3_metadata=1 в случае, если идут метаданные. В остальных случаях отсылаются данные, как и прежде.
|
|||
|
|
|
|||
|
|
Применик перед запросом смотрит, будет ли хранить данные в S3. Провеока сейчас кривая - запрашивается резервирование на диске с наибольшим доступным местом, а потом смотрится, не на S3 ли оно.
|
|||
|
|
Если на S3, то отсылает в запросе send_s3_metadata=1.
|
|||
|
|
|
|||
|
|
Источник при получении такого запроса смотрит, лежит ли парт на S3. Если да, то в Зукипере ставит метку по пути `<путь к данным таблицы>/zero_copy_s3/<некий ID парта>/<ID реплики>`,
|
|||
|
|
ставит в ответ куку send_s3_metadata=1 и вместо файлов с данными отсылает только файлы метаданных.
|
|||
|
|
|
|||
|
|
Приемник при получении ответа с send_s3_metadata=1 создает только файлики с идентичными меаданными, которые в итоге будут ссылаться на те же ключи в S3, ставит в зукипере аналогичную метку,
|
|||
|
|
только со своим ID реплики, и работает с этим.
|
|||
|
|
|
|||
|
|
При желании удалить парт нода удаляет в Зукипере ключ `<путь к данным таблицы>/zero_copy_s3/<некий ID парта>/<ID реплики>`, потом получает все подключи `<путь к данным таблицы>/zero_copy_s3/<некий ID парта>`.
|
|||
|
|
Если список не пустой, то считает, что данные использует другая нода и удаляет только локальные метаданные, если пустой, то удаляет и данные в S3.
|
|||
|
|
|
|||
|
|
## Костыли и недоработки, коих много
|
|||
|
|
|
|||
|
|
* Никакой проверки, один и тот же S3 у нод или разный сейчас нет, если будет несколько разных S3, работать не будет.
|
|||
|
|
|
|||
|
|
* В качестве ID парта берется имя первого S3-ключа от файла checksums.txt.
|
|||
|
|
|
|||
|
|
* Не нашел удобного способа прокидывать в коде зукипер, прокинул хадркодом.
|
|||
|
|
|
|||
|
|
* При удалении класс диска ничего не знает про парты, прокинул флаг, что надо оставлять данные в S3 параметром, это очень криво получилось.
|
|||
|
|
|
|||
|
|
* Возможна гонка, если источник отошлет метаданные про парт и тут же решит его удалить до того, как приемник поставит в зукипер пометку.
|
|||
|
|
|
|||
|
|
* В протоколе репликации обмен инфой через параметр запрос в одну сторону и куку в другую мне не нравится, хотя так сделан обмен версиями репликации.
|
|||
|
|
|
|||
|
|
* При ошибке должно пытаться реплицироваться по старому, но хз, всегда ли сработает
|
|||
|
|
|
|||
|
|
* Не будет обратной совместимости, если образуются такие шареные парты, откатиться на старую версию кликхауса не получится, иначе нода может удалить используемые другой данные.
|
|||
|
|
|
|||
|
|
* И вообще
|