Return-Path: X-Original-To: archive-asf-public-internal@cust-asf2.ponee.io Delivered-To: archive-asf-public-internal@cust-asf2.ponee.io Received: from cust-asf.ponee.io (cust-asf.ponee.io [163.172.22.183]) by cust-asf2.ponee.io (Postfix) with ESMTP id D2DF1200CC2 for ; Tue, 20 Jun 2017 13:59:07 +0200 (CEST) Received: by cust-asf.ponee.io (Postfix) id D16A8160BD3; Tue, 20 Jun 2017 11:59:07 +0000 (UTC) Delivered-To: archive-asf-public@cust-asf.ponee.io Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by cust-asf.ponee.io (Postfix) with SMTP id 24DDD160BE1 for ; Tue, 20 Jun 2017 13:59:06 +0200 (CEST) Received: (qmail 47581 invoked by uid 500); 20 Jun 2017 11:59:06 -0000 Mailing-List: contact issues-help@hbase.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Delivered-To: mailing list issues@hbase.apache.org Received: (qmail 47516 invoked by uid 99); 20 Jun 2017 11:59:05 -0000 Received: from pnap-us-west-generic-nat.apache.org (HELO spamd2-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 20 Jun 2017 11:59:05 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd2-us-west.apache.org (ASF Mail Server at spamd2-us-west.apache.org) with ESMTP id 030081B0D1A for ; Tue, 20 Jun 2017 11:59:05 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd2-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: -100.002 X-Spam-Level: X-Spam-Status: No, score=-100.002 tagged_above=-999 required=6.31 tests=[RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=disabled Received: from mx1-lw-us.apache.org ([10.40.0.8]) by localhost (spamd2-us-west.apache.org [10.40.0.9]) (amavisd-new, port 10024) with ESMTP id rxjcqYkRzCzU for ; Tue, 20 Jun 2017 11:59:03 +0000 (UTC) Received: from mailrelay1-us-west.apache.org (mailrelay1-us-west.apache.org [209.188.14.139]) by mx1-lw-us.apache.org (ASF Mail Server at mx1-lw-us.apache.org) with ESMTP id B0BD95F523 for ; Tue, 20 Jun 2017 11:59:02 +0000 (UTC) Received: from jira-lw-us.apache.org (unknown [207.244.88.139]) by mailrelay1-us-west.apache.org (ASF Mail Server at mailrelay1-us-west.apache.org) with ESMTP id 99A2EE0DD0 for ; Tue, 20 Jun 2017 11:59:01 +0000 (UTC) Received: from jira-lw-us.apache.org (localhost [127.0.0.1]) by jira-lw-us.apache.org (ASF Mail Server at jira-lw-us.apache.org) with ESMTP id 32FD124017 for ; Tue, 20 Jun 2017 11:59:00 +0000 (UTC) Date: Tue, 20 Jun 2017 11:59:00 +0000 (UTC) From: "Jan Kunigk (JIRA)" To: issues@hbase.apache.org Message-ID: In-Reply-To: References: Subject: [jira] [Commented] (HBASE-16415) Replication in different namespace MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 archived-at: Tue, 20 Jun 2017 11:59:08 -0000 [ https://issues.apache.org/jira/browse/HBASE-16415?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16055630#comment-16055630 ] Jan Kunigk commented on HBASE-16415: ------------------------------------ I mean that, adding the method to ReplicationEndpoint would define a general interface for redirecting entries. Other Endpoints (RegionReplicaReplicationEndpoint, or new future ones) could implement a redirectEntries() method too if they want to provide this, maybe with slightly different semantics. Maybe those Endpoints would choose slightly different semantics for their own implementation of redirectEntries(). If they do not provide an implementation, then the empty default implementation from the interface will kick in. If we implement redirection within RedirectingInterClusterReplicationEndpoint.createBatches(), the concept of redirection would not be exposed beyond RedirectingInterClusterReplicationEndpoint. I do not have enough experience with the HBase codebase to weigh the merits of making this a general interface vs. encapsulating this functionality in the new endpoint entirely and will rely on your guidance. I hope I could clarify my idea though. J > Replication in different namespace > ---------------------------------- > > Key: HBASE-16415 > URL: https://issues.apache.org/jira/browse/HBASE-16415 > Project: HBase > Issue Type: New Feature > Components: Replication > Reporter: Christian Guegi > Assignee: Jan Kunigk > > It would be nice to replicate tables from one namespace to another namespace. > Example: > Master cluster, namespace=default, table=bar > Slave cluster, namespace=dr, table=bar > Replication happens in class ReplicationSink: > public void replicateEntries(List entries, final CellScanner cells, ...){ > ... > TableName table = TableName.valueOf(entry.getKey().getTableName().toByteArray()); > ... > addToHashMultiMap(rowMap, table, clusterIds, m); > ... > for (Entry, List>> entry : rowMap.entrySet()) { > batch(entry.getKey(), entry.getValue().values()); > } > } -- This message was sent by Atlassian JIRA (v6.4.14#64029)