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
To be universal it seems like the proposed solution would require adding <name> to each replica and shard in the cluster definition, <includes_current_node>true</includes_current_node> for each cluster with current node to determine that we are in it, <shard> and <replica> macros must be filled and every cluster must be defined the same way on all the replicas. From the developer side, we would need to add a new version of DDLTask with a new flag at the end on whether we use this optional feature or not and a list of replica|shard names.
What sounds like a much easier solution, we add a macro <hostname>, and if it is specified, we will not try to resolve any of the hostnames, but simply compare it and find out whether we need to execute this query or not. For this, the hostname of the current node needs to be the same in all of the config configurations, but it looks a lot more manageable.
Using hostname as identifier in distributed systems coordination is a error-prone idea. DNS can be unavailable anytime and in this case participants will be unable to identify who is who and who they are. We have an example of such issue in DDLWorker:
https://github.com/ClickHouse/clickhouse/blob/master/src/Interpreters/DDLTask.cpp#L218-L286.
The idea is to introduce identifier for each host participating in cluster in addition to existing fields https://github.com/ClickHouse/clickhouse/blob/master/src/Interpreters/Cluster.h#L93-L109. By default we can use value of
<replica>|<shard>
macros for this identifier. Other option is sever UUID.Instead of hostnames https://github.com/ClickHouse/clickhouse/blob/master/src/Interpreters/executeDDLQueryOnCluster.cpp#L116-L124 we will use this unique identifiers and always be able to verify who has to execute which entry without any issues related to DNS.
However this behavior is new and require proper specification of macros values in config. So it should be optional by default.
The text was updated successfully, but these errors were encountered: