alex-plekhanov commented on a change in pull request #8668: URL: https://github.com/apache/ignite/pull/8668#discussion_r564555912
########## File path: modules/core/src/main/java/org/apache/ignite/cache/affinity/rendezvous/ClusterNodeAttributeColocatedBackupFilter.java ########## @@ -0,0 +1,114 @@ +/* + * Licensed to the Apache Software Foundation (ASF) under one or more + * contributor license agreements. See the NOTICE file distributed with + * this work for additional information regarding copyright ownership. + * The ASF licenses this file to You under the Apache License, Version 2.0 + * (the "License"); you may not use this file except in compliance with + * the License. You may obtain a copy of the License at + * + * http://www.apache.org/licenses/LICENSE-2.0 + * + * Unless required by applicable law or agreed to in writing, software + * distributed under the License is distributed on an "AS IS" BASIS, + * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. + * See the License for the specific language governing permissions and + * limitations under the License. + */ + +package org.apache.ignite.cache.affinity.rendezvous; + +import java.util.List; +import java.util.Objects; +import org.apache.ignite.cluster.ClusterNode; +import org.apache.ignite.lang.IgniteBiPredicate; + +/** + * This class can be used as a {@link RendezvousAffinityFunction#affinityBackupFilter } to create + * cache templates in Spring that force each partition's primary and backup to be co-located on nodes with the same + * attribute value. + * <p> + * + * Partition copies co-location can be helpful to group nodes into cells when fixed baseline topology is used. If all + * copies of each partition are located inside only one cell, in case of {@code backup + 1} nodes leave the cluster + * there will be data lost only if all leaving nodes belong to the same cell. Without partition copies co-location + * within a cell, most probably there will be data lost if any {@code backup + 1} nodes leave the cluster. + * + * Note: Baseline topology change can lead to inter-cell partitions migration, i.e. rebalance can affect all copies + * of some partitions even if only one node is changed in the baseline topology. + * <p> + * + * This implementation will discard backups rather than place copies on nodes with different attribute values. This + * avoids trying to cram more data onto remaining nodes when some have failed. + * <p> + * A node attribute to compare is provided on construction. + * + * Note: All cluster nodes, on startup, automatically register all the environment and system properties as node + * attributes. + * + * Note: Node attributes persisted in baseline topology at the time of baseline topology change. If the co-location + * attribute of some node was updated, but the baseline topology wasn't changed, the outdated attribute value can be + * used by the backup filter when this node left the cluster. To avoid this, the baseline topology should be updated + * after changing the co-location attribute. + * <p> + * This class is constructed with a node attribute name, and a candidate node will be rejected if previously selected + * nodes for a partition have a different value for attribute on the candidate node. + * </pre> + * <h2 class="header">Spring Example</h2> + * Create a partitioned cache template plate with 1 backup, where the backup will be placed in the same cell + * as the primary. Note: This example requires that the environment variable "CELL" be set appropriately on + * each node via some means external to Ignite. + * <pre name="code" class="xml"> + * <property name="cacheConfiguration"> + * <list> + * <bean id="cache-template-bean" abstract="true" class="org.apache.ignite.configuration.CacheConfiguration"> + * <property name="name" value="JobcaseDefaultCacheConfig*"/> + * <property name="cacheMode" value="PARTITIONED" /> + * <property name="backups" value="1" /> + * <property name="affinity"> + * <bean class="org.apache.ignite.cache.affinity.rendezvous.RendezvousAffinityFunction"> + * <property name="affinityBackupFilter"> + * <bean class="org.apache.ignite.cache.affinity.rendezvous.ClusterNodeAttributeColocatedBackupFilter"> + * <!-- Backups must go to the same CELL as primary --> + * <constructor-arg value="CELL" /> + * </bean> + * </property> + * </bean> + * </property> + * </bean> + * </list> + * </property> + * </pre> + * <p> + */ +public class ClusterNodeAttributeColocatedBackupFilter implements IgniteBiPredicate<ClusterNode, List<ClusterNode>> { + /** */ + private static final long serialVersionUID = 1L; + + /** Attribute name. */ + private final String attrName; + + /** + * @param attrName The attribute name for the attribute to compare. + */ + public ClusterNodeAttributeColocatedBackupFilter(String attrName) { + this.attrName = attrName; + } + + /** + * Defines a predicate which returns {@code true} if a node is acceptable for a backup + * or {@code false} otherwise. An acceptable node is one where its attribute value + * is exact match with previously selected nodes. If an attribute does not Review comment: If a node was restarted without an attribute value it will be treated as another cell with an empty attribute value, so, there will be no data lost (but sometimes rebalance). If we will shutdown the nodes by failure handler in case of a node with an empty attribute value joined then all cluster nodes will be failed one by one in some, unexpected to user moment (when the coordinator is changed, or when a new cache is started, or when baseline topology is changed, but not when the node with wrong attribute value joined the cluster). I think it's even worse than allow null attribute values. I didn't get how the code in this snippet will help to avoid null attribute values. It checks attribute names at construction time, but not attribute values of joined nodes. If we will store attribute value in the metastore it will be unclear to the user how to reconfigure it (even with documentation it will be complicated and risky). ---------------------------------------------------------------- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: [email protected]
