Hello!
Too many unrelated issues are wrapped together here.
First, you do not need to have identical config for all nodes in the
cluster. Paths may surely differ. Some property need to be the same, some
don't.
Second, you may change the node's consistentId to specify which persistence
files to use, even if their config is otherwise identical. If consistentId
is not used then one node may capture the data dir and the second one will
not be able to use it / create one from scratch.
Last, nodes may be added to cluster at any time but you should make sure
that baseline topology is fixed also. Node is not added/removed to baseline
topology unless you do that manually. You may also configure auto-adjust.
Regards,
--
Ilya Kasnacheev
пт, 20 нояб. 2020 г. в 13:08, Wolfgang Meyerle <
wolfgang.meye...@googlemail.com>:
> Hi community,
>
> I have a question regarding the xml configuration which is used in
> clients / servers and thinclients.
>
> Is it really necessary that each node is using the same configuration?
> I'm just asking because I'm trying out to setup multiple servers in one
> machine which totally is nonsense in a production release but worth
> working in a debugging environment and to find out how Ignite acts in
> certain use cases.
>
> I started basically two server configurations. One from a cpp code
> environment and the other from the usual ./ignite.sh bash script which
> has been provided with the release.
>
> The ignite environment was started first and somehow seems to block the
> cpp code from inserting data into the persistent storage as I cannot see
> my log output but just that the node has started up.
>
> After I started the ignite.sh script I activated the server node with
> control.sh --activate
>
> Is that maybe the problem as new nodes are not accepted anymore to be
> joined to the topology?
>
> Why do I have to activate the nodes or deactivate them anyway in the
> first place. In my mind the servers should be shutdown when the last
> node leaves the topology
>
> Regards,
>
> Wolfgang
>
