-
Notifications
You must be signed in to change notification settings - Fork 6.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
S3 zero copy replication #16240
S3 zero copy replication #16240
Conversation
123025c
to
d5bc7ad
Compare
d5bc7ad
to
652c56e
Compare
698e68c
to
4f7065e
Compare
4f7065e
to
e3879af
Compare
S3ZeroCopyReplication.md
Outdated
Приемник в ответ отсылает куку send_s3_metadata=1 в случае, если идут метаданные. В остальных случаях отсылаются данные, как и прежде. | ||
|
||
Применик перед запросом смотрит, будет ли хранить данные в S3. Проверка сейчас кривая - если в сторадже есть S3, то считаем, что будет S3. | ||
Если да S3, то отсылает в запросе send_s3_metadata=1. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Строго говоря не исключена ситуация когда и приёмник и передатчик на s3 но банкеты разные. Наверное надо адрес бакета отправлять или какой-то хэш от него.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Адрес может быть разным в случае например нахождения нод в разных ДЦ и использования разных прокси для доступа к S3. В качестве страховки приемник после получения метаданных проверяет доступность (фактически - наличие в S3 первого объекта от первого файла, не скачивая, в просто через list), и если данные не доступны, то сваливается в старый механизм с полноценной копией.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Бонусом дешево получилась возможность работы с несколькими разными S3, когда у разных нод разная очередность (перебирает все S3 в сторадже в поисках нужного). Но непонятно, кому это может пригодиться. :)
0899321
to
1742fb3
Compare
b8f9f57
to
eba98b0
Compare
If multiple replicas share the same storage, how to resolve the share file confliction when the diffrent replicas to excute insert and merge? |
I think need to consider the ddl worker, no need to do the ddl on the all replicas. |
On insert one replica creates all files of part, after that files never changes. |
885ae9e
to
18ff577
Compare
18ff577
to
aff13c0
Compare
…o s3_zero_copy_replication
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok, but need to remove suspicious if.
Yarrr! Conflict on ErrorCode. |
Can I know whether this change will be merged to 21.3-lts? If yes, do we have any timeline? Thanks! |
namespace DB | ||
{ | ||
|
||
struct DiskType |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This looks like antipattern.
And there is zero comments in this file 😭
What does it mean "disk type" and why do we need to discriminate them?
Maybe remove this file and all its usages?
I hereby agree to the terms of the CLA available at: https://yandex.ru/legal/cla/?lang=en
Changelog category (leave one):
Changelog entry (a user-readable short description of the changes that goes to CHANGELOG.md):
Zero-copy replication for ReplicatedMergeTree over S3 storage
Detailed description / Documentation draft:
Zero-copy replication over S3 storage