ClickHouse/tests/integration/test_part_uuid/configs/remote_servers.xml

<yandex>
    <remote_servers>
        <test_cluster>
            <shard>
                <replica>
                    <host>node1</host>
                    <port>9000</port>
                </replica>
            </shard>
            <shard>
                <replica>
                    <host>node2</host>
                    <port>9000</port>
                </replica>
            </shard>
        </test_cluster>
    </remote_servers>
</yandex>
Add unique identifiers IMergeTreeDataPart structure For now uuids are not generated at all, they are present only if the part is updated manually (as you can see in the integration test). The only place where they can be seen today by an end user is in `system.parts` table. I was looking for hiding this column behind an option but couldn't find an easy way to do that. Likely this is also required for WAL, but need to think how not to break compatibility. Relates to #13574, https://github.com/ClickHouse/ClickHouse/issues/13574 Next 1: In the upcoming PR the plan is to integrate de-duplication based on these fingerprints in the query pipeline. Next 2: We'll enable automatic generation of uuids and come up with a way for conditionally sending uuids when processing distributed queries only when part movement is in progress. 2020-10-15 16:17:16 +00:00			`<yandex>`
			`<remote_servers>`
			`<test_cluster>`
			`<shard>`
			`<replica>`
			`<host>node1</host>`
			`<port>9000</port>`
			`</replica>`
			`</shard>`
			`<shard>`
			`<replica>`
			`<host>node2</host>`
			`<port>9000</port>`
			`</replica>`
			`</shard>`
			`</test_cluster>`
			`</remote_servers>`
Assign UUIDs to parts only when configured to do so Avoid breaking backwards compatibility by default for now. 2020-11-02 14:38:18 +00:00			`</yandex>`