hi Ignite team, Moved the question from below link to this new one to reduce confusion with a proper title. http://apache-ignite-users.70518.x6.nabble.com/How-to-use-the-logger-in-the-BackupFilter-tt6442.html
Val> I recommend to group nodes using attributes (IgniteConfiguration.setUserAttributes() property) and use them in the backup filter. Basically, the filter should return false if both provided nodes are in the same group. a) I use .Net version of ignite, does it support the user attributes in the IgniteConfiguration now? b) In the BackupFilter, the parameter is (PrimaryNode, BackupNodeCandidate) pair, so can only assign backup node to different group with primary node, but cannot assign all the backup nodes to different groups between each other, right? E.g. say backups = 2 and node lists returned from Rendezvous hash = (A1, B2, C2, D3, E1, ...), letter is machine name and digit is group. According to the current BackupFilter.apply interface, (A1, B2, C2) is selected. But when primary node A1 is down, (B2, D3, E1) will be selected. Then will C2 be released and D3, E1 be copied with the data? Is this a problem? If get the node list (A1, B2, D3) not (A1, B2, C2), can reduce the impact of primary node's failure. In order to do this, do I need to change the BackupFilter.apply interface to add another parameter for the already selected nodes or change the RendezvousAffinityFunction.assignPartition directly? or any other better solution? c) Event with user attributes, but when do the deployment of adding new machines to the node, it will roll out one machine group by one, so this means during the period of deployment, all the nodes cannot get the same user attributes (machines group info) and if the Rendezvous hashing return a new machine list for one partition with the new machine in the top N (N is the backup # + 1), the backup filter in different nodes may made different decision. E.g. for partition p of cache c, its node list after Rendezvous hashing is A1, X1, B2, C3, D2, ..., where X is a new added machine and for rolled machine, its group is 1 but for others, it's unknown; and suppose the backup = 2. Say, we've rolled out group 1 and are rolling out group 2 now, so in machine A, it selects (A1, B2, C3), but in machine C, it may select (A1, X, B2), because it doesn't know which group X belongs to now. This will cause inconsistency. BTW, what will happen for this inconsistency if it really happen? FYI, we've use only in-memory for the data and don't expect data loss in the deployment. d) I can use another central-control store, e.g. ZooKeeper, to maintain this info, when ignite start, will register an ephemeral node for the machine and its group, and when exit, the ephemeral node will be deleted automatically. And in the BackupFilter, read the ZK to get the group info for the nodes. But this seems a little complicated. e) BTW, this should be a very common problem for the production usage with data only in memory, and does the Enterprise version provide any reliable solution for this? Thanks, -Jason -- View this message in context: http://apache-ignite-users.70518.x6.nabble.com/How-to-use-BackupFilter-to-assign-all-backups-to-different-machine-groups-tp6513.html Sent from the Apache Ignite Users mailing list archive at Nabble.com.
