[
https://issues.apache.org/jira/browse/KUDU-687?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15436227#comment-15436227
]
Adar Dembo commented on KUDU-687:
---------------------------------
I looked into what information ksck needs from the master. Here are my findings:
{noformat}
Using ListTabletServers, fetch tservers:
- first RPC address
- uuid
Using ListTables, fetch table names
Using GetTableSchema, fetch table metadata:
- schema
- number of replicas
Using GetTableLocations, fetch tablet metadata for each table:
- table id
- replicas:
- role
- ts uuid
{noformat}
Out of the above, here are the missing pieces:
# We'd need to convert from KuduSchema to Schema. But we can already do that
using an existing internal method; just need to make ksck a friend of
KuduSchema.
# We'd need to expose the number of replicas of the table. Seems like a useful
thing to do in general.
# The biggest missing piece is GetTableLocations. The Java client has methods
that expose everything but the replica's ts UUID, though those methods are
deprecated. Like the number of replicas, I think exposing this would be net
useful. It's possible we may be able to adapt the ScanToken API to provide this
information; I haven't looked into that.
As to the other approach, it's not as simple as exposing SyncLeaderMasterRpc.
That's a KuduClient function and its quite stateful. We'd need to pull out more
functionality. I'm not quite sure how deep that rabbit hole goes, and IMHO it's
a Frankenstein-like architecture.
> ksck should work against multi-master
> -------------------------------------
>
> Key: KUDU-687
> URL: https://issues.apache.org/jira/browse/KUDU-687
> Project: Kudu
> Issue Type: Bug
> Components: ops-tooling
> Affects Versions: Public beta
> Reporter: Todd Lipcon
>
> ksck currently creates an rpc proxy directly to the master, and is only
> configured by a single address. This doesn't work in a multi-master cluster.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
