yifan-c commented on code in PR #212: URL: https://github.com/apache/cassandra-sidecar/pull/212#discussion_r2120249541
########## server/src/main/java/org/apache/cassandra/sidecar/config/LiveMigrationConfiguration.java: ########## @@ -0,0 +1,48 @@ +/* + * 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.cassandra.sidecar.config; + +import java.util.Map; +import java.util.Set; + +/** + * Configuration for Live Migration feature. + */ +public interface LiveMigrationConfiguration +{ + + /** + * Files to be excluded from Live Migration. + * @return set of file exclusion patterns. + */ + Set<String> filesToExclude(); + + /** + * Directories to be excluded from Live Migration. + * @return set of directory exclusion patterns. + */ + Set<String> directoriesToExclude(); + + /** + * Map of source and destination Cassandra instances to migrate. + * + * @return Map of strings where key is the source instance name and value is the destination instance name. + */ + Map<String, String> migrationMap(); +} Review Comment: > This migration talks about migrating Cassandra instance with in a cluster rather than moving nodes from one cluster to another. Thanks for the correction. I was under the wrong impression of the migration. It is simpler when migrating within a cluster coordinated by Sidecar. The sidecar instances (both source and target) have access to Cassandra. The motivation of my idea is to avoid the operational pain from the configuration approach. The equivalent configuration can be persisted in the database. > In pull model scenarios, Source instances should handle deletions. I guess you meant the "coordinated" scenario that I described? The target Sidecar instances can still run diff and delete in the coordinated mode. For example, a coordinator in Source issues a sync to the sidecar instance in Target and ask it to check diff and sync (delete files no longer present in source, and download files not yet downloaded) according to the persisted configuration. Vast majority of the flow is the same as described in CEP-40. The advantage is having all the control via the API (e.g. operators do not need to update configuration in the source instances). Or, we can also stick with the idea of having the "tooling" to coordinate, as depicted in CEP-40. In that case, the only difference is storing configuration in Cassandra. It should achieve the idea of not bouncing sidecar instances. That being said, it is not necessary to block on the merge of this patch (as you are adding the patches of the feature). Please re-think about the suggestion. We can talk more offline. > supporting migration from different sources like S3 I am not sure how S3 fits in the live-migration scenario. If you are thinking about restoring from a snapshot on S3, it is not live. If you are thinking about downloading from analytics bulk written data, it is not migration. The goal of live-migration is to moving data from one Cassandra node to another with zero downtime. -- 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. To unsubscribe, e-mail: pr-unsubscr...@cassandra.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: pr-unsubscr...@cassandra.apache.org For additional commands, e-mail: pr-h...@cassandra.apache.org
