5.0 KiB
ClickHouse S3 Zero Copy Replication
Говнокод просто для теста, не production-ready ни разу.
Как сделано
При 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 параметром, это очень криво получилось.
-
Возможна гонка, если источник отошлет метаданные про парт и тут же решит его удалить до того, как приемник поставит в зукипер пометку.
-
В протоколе репликации обмен инфой через параметр запрос в одну сторону и куку в другую мне не нравится, хотя так сделан обмен версиями репликации.
-
При ошибке должно пытаться реплицироваться по старому, но хз, всегда ли сработает
-
Не будет обратной совместимости, если образуются такие шареные парты, откатиться на старую версию кликхауса не получится, иначе нода может удалить используемые другой данные.
-
И вообще