[jira] [Created] (KUDU-3250) Add a test case for accidental addition, removal and the re-addition of a master
Bankim Bhavsar created KUDU-3250:
Summary: Add a test case for accidental addition, removal and the
re-addition of a master
Key: KUDU-3250
URL: https://issues.apache.org/jira/browse/KUDU-3250
Project: Kudu
Issue Type: Test
Components: master, test
Reporter: Bankim Bhavsar
Quoting [~aserbin] from code review for remove master CLI
https://gerrit.cloudera.org/c/17010/9/src/kudu/master/dynamic_multi_master-test.cc#1202
{quote}
Not sure I missed a test I was looking for, but what do you think about adding
a test for a use case when first a new master is added mistakenly (say, using a
valid, but not intended host), and then rolling back such a change, targeting
to run 'kudu add master' again with correct destination node?
That's about having a sequence of 'kudu master add
', immediately followed by 'kudu master remove
'?
{quote}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (KUDU-3249) Add a test case for recovering a dead master at the same HostPort
Bankim Bhavsar created KUDU-3249: Summary: Add a test case for recovering a dead master at the same HostPort Key: KUDU-3249 URL: https://issues.apache.org/jira/browse/KUDU-3249 Project: Kudu Issue Type: Test Components: master, test Reporter: Bankim Bhavsar Once we have the basic add and remove master primitives in place, add a test case that simulates recovering a dead master at the same HostPort but possibly different uuid. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (KUDU-3246) Add a test case for master removal when there are multiple masters with same HostPort
[ https://issues.apache.org/jira/browse/KUDU-3246?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bankim Bhavsar updated KUDU-3246: - Issue Type: Test (was: Improvement) > Add a test case for master removal when there are multiple masters with same > HostPort > - > > Key: KUDU-3246 > URL: https://issues.apache.org/jira/browse/KUDU-3246 > Project: Kudu > Issue Type: Test > Components: master, test >Affects Versions: 1.15.0 >Reporter: Bankim Bhavsar >Priority: Major > > Remove master code handles the case when there are multiple masters with same > HostPort and no uuid is specified causing ambiguity in terms of which master > needs to be removed. > https://github.com/apache/kudu/blob/master/src/kudu/master/master.cc#L582 > However we don't have a test case for the same. So filing a JIRA to track the > same. > See review comment: > https://gerrit.cloudera.org/c/17010/7/src/kudu/master/dynamic_multi_master-test.cc#874 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (KUDU-3248) Expose replica selection option that provides better affinity for remote scans
[ https://issues.apache.org/jira/browse/KUDU-3248?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Grant Henke reassigned KUDU-3248: - Assignee: Grant Henke > Expose replica selection option that provides better affinity for remote scans > -- > > Key: KUDU-3248 > URL: https://issues.apache.org/jira/browse/KUDU-3248 > Project: Kudu > Issue Type: Improvement > Components: client >Reporter: David Rorke >Assignee: Grant Henke >Priority: Major > > Kudu clients like Impala that use the CLOSEST_REPLICA selection option can > suffer from bad tserver buffer cache warmup/locality during remote scans due > to lack of tserver affinity as described in IMPALA-10481. > The Kudu client should expose a replica selection option that provides better > affinity when doing remote scans. The comments in IMPALA-10481 suggest a > new LOCAL_OR_LEADER option that would select a local replica if one exists, > otherwise fallback to the leader. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (KUDU-3248) Expose replica selection option that provides better affinity for remote scans
David Rorke created KUDU-3248: - Summary: Expose replica selection option that provides better affinity for remote scans Key: KUDU-3248 URL: https://issues.apache.org/jira/browse/KUDU-3248 Project: Kudu Issue Type: Improvement Components: client Reporter: David Rorke Kudu clients like Impala that use the CLOSEST_REPLICA selection option can suffer from bad tserver buffer cache warmup/locality during remote scans due to lack of tserver affinity as described in IMPALA-10481. The Kudu client should expose a replica selection option that provides better affinity when doing remote scans. The comments in IMPALA-10481 suggest a new LOCAL_OR_LEADER option that would select a local replica if one exists, otherwise fallback to the leader. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (KUDU-3247) UUID column type
[ https://issues.apache.org/jira/browse/KUDU-3247?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Grant Henke updated KUDU-3247: -- Labels: roadmap-candidate (was: ) > UUID column type > > > Key: KUDU-3247 > URL: https://issues.apache.org/jira/browse/KUDU-3247 > Project: Kudu > Issue Type: Improvement >Reporter: Grant Henke >Priority: Major > Labels: roadmap-candidate > > It could be useful to have a UUID column type in Kudu given often when users > can't find a natural key, they look to a UUID as an alternate option. The > problem with this is that the UUID value is often stored in a STRING or > BINARY column resulting a random ordered write workload which puts a lot of > strain on Kudu compaction for high volumes. > If Kudu has a native UUID type it can leverage the underlying structure of > the UUID to benefit from the mostly ordered properties (version 1 and the > proposed version 6 UUIDs have a date-time component). > The implementation could be a logical type built on top of BYTES or INT128. > The client should have methods to write the UUID type using encoded UUID > strings or UUID objects. > Here are some references/examples of a UUID type: > * https://docs.yugabyte.com/latest/api/ycql/type_uuid/ > * https://cloud.google.com/spanner/docs/schema-design#uuid_primary_key > * https://www.percona.com/blog/2014/12/19/store-uuid-optimized-way/ > * http://gh.peabody.io/uuidv6/ > * https://github.com/f4b6a3/uuid-creator#version-6-time-ordered-proposed -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (KUDU-3247) UUID column type
Grant Henke created KUDU-3247: - Summary: UUID column type Key: KUDU-3247 URL: https://issues.apache.org/jira/browse/KUDU-3247 Project: Kudu Issue Type: Improvement Reporter: Grant Henke It could be useful to have a UUID column type in Kudu given often when users can't find a natural key, they look to a UUID as an alternate option. The problem with this is that the UUID value is often stored in a STRING or BINARY column resulting a random ordered write workload which puts a lot of strain on Kudu compaction for high volumes. If Kudu has a native UUID type it can leverage the underlying structure of the UUID to benefit from the mostly ordered properties (version 1 and the proposed version 6 UUIDs have a date-time component). The implementation could be a logical type built on top of BYTES or INT128. The client should have methods to write the UUID type using encoded UUID strings or UUID objects. Here are some references/examples of a UUID type: * https://docs.yugabyte.com/latest/api/ycql/type_uuid/ * https://cloud.google.com/spanner/docs/schema-design#uuid_primary_key * https://www.percona.com/blog/2014/12/19/store-uuid-optimized-way/ * http://gh.peabody.io/uuidv6/ * https://github.com/f4b6a3/uuid-creator#version-6-time-ordered-proposed -- This message was sent by Atlassian Jira (v8.3.4#803005)
