[jira] [Updated] (KUDU-1580) Connection negotiation timeout to tablet server is treated as unretriable error
[ https://issues.apache.org/jira/browse/KUDU-1580?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Serbin updated KUDU-1580: Resolution: Fixed Fix Version/s: 1.4.0 Status: Resolved (was: In Review) Fixed with e3c5dd18c22b9e20358f05dcd301e7736c0a3321 > Connection negotiation timeout to tablet server is treated as unretriable > error > --- > > Key: KUDU-1580 > URL: https://issues.apache.org/jira/browse/KUDU-1580 > Project: Kudu > Issue Type: Bug > Components: client >Affects Versions: 0.10.0 >Reporter: Todd Lipcon >Assignee: Alexey Serbin >Priority: Critical > Labels: client > Fix For: 1.4.0 > > > In the case that the leader tablet server is up but "frozen", the client will > get a connection negotiation timeout trying to establish an RPC connection. > It appears that this Status::TimeOut() is treated as a non-retriable error by > WriteRpc::AnalyzeResponse, so the client gets a failure even if there has > been a leader re-election within the client-provided deadline. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (KUDU-2024) Clarify on semantics of ServerPicker::MarkServerFailed() method
Alexey Serbin created KUDU-2024:
---
Summary: Clarify on semantics of ServerPicker::MarkServerFailed()
method
Key: KUDU-2024
URL: https://issues.apache.org/jira/browse/KUDU-2024
Project: Kudu
Issue Type: Task
Reporter: Alexey Serbin
As one can see from the discussion at [review item for
KUDU-1034|https://gerrit.cloudera.org/#/c/6924], the semantics of
{{ServerPicker::MarkServerFailed()}} method is not really clear, especially
given the fact the implementation of that method in {{MetaCacheServerPicker}}
class does not actually mark the whole server as failed.
It would be nice to clarify on that and change the name (or introduce the new
method), if necessary.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Resolved] (KUDU-1860) ksck doesn't identify tablets that are evicted but still in config
[
https://issues.apache.org/jira/browse/KUDU-1860?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Will Berkeley resolved KUDU-1860.
-
Resolution: Fixed
Fix Version/s: 1.4.0
Resolved in e2097c8b93ad7860712cc489ef9dcd64a0ac09f8
> ksck doesn't identify tablets that are evicted but still in config
> --
>
> Key: KUDU-1860
> URL: https://issues.apache.org/jira/browse/KUDU-1860
> Project: Kudu
> Issue Type: Bug
> Components: ksck, ops-tooling
>Affects Versions: 1.2.0
>Reporter: Jean-Daniel Cryans
>Assignee: Will Berkeley
> Fix For: 1.4.0
>
>
> As reported by a user on Slack, ksck can give you a wrong output such as:
> {noformat}
> ca199fafca544df2a1b2a01be9d5266d (server1:7250): RUNNING [LEADER]
> a077957f627c4758ab5a989aca8a1ca8 (server2:7250): RUNNING
> 5c09a555c205482b8131f15b2c249ec6 (server3:7250): bad state
> State: NOT_STARTED
> Data state: TABLET_DATA_TOMBSTONED
> Last status: Tablet initializing...
> {noformat}
> The problem is that server2 was already evicted out of the configuration
> (based on reading the logs) but it wasn't committed in the config (which
> contains server 1 and 3) since there's really only 1 server left out of 3.
> Ideally ksck should try to see what each server thinks the configuration is
> and see if there's a difference from what's in the master. As it is, it looks
> like we're missing 1 replica but in reality this is a broken tablet.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (KUDU-1563) Add support for INSERT IGNORE
[
https://issues.apache.org/jira/browse/KUDU-1563?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16023757#comment-16023757
]
Brock Noland commented on KUDU-1563:
Useful [link|https://mariadb.com/kb/en/mariadb/insert-on-duplicate-key-update/]
to understand the differences between {{UPSERT}} and {{ON DUPLICATE KEY
UPDATE}}
> Add support for INSERT IGNORE
> -
>
> Key: KUDU-1563
> URL: https://issues.apache.org/jira/browse/KUDU-1563
> Project: Kudu
> Issue Type: New Feature
>Reporter: Dan Burkert
>Assignee: Brock Noland
> Labels: newbie
>
> The Java client currently has an [option to ignore duplicate row key errors|
> https://kudu.apache.org/apidocs/org/kududb/client/AsyncKuduSession.html#setIgnoreAllDuplicateRows-boolean-],
> which is implemented by filtering the errors on the client side. If we are
> going to continue to support this feature (and the consensus seems to be that
> we probably should), we should promote it to a first class operation type
> that is handled on the server side. This would have a modest perf.
> improvement since less errors are returned, and it would allow INSERT IGNORE
> ops to be mixed in the same batch as other INSERT, DELETE, UPSERT, etc. ops.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (KUDU-1563) Add support for INSERT IGNORE
[
https://issues.apache.org/jira/browse/KUDU-1563?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16023372#comment-16023372
]
Dan Burkert commented on KUDU-1563:
---
Just learned about a usecase that would be well-served by an {{ON DUPLICATE KEY
UPDATE}} mechanism in Kudu. In particular, the workload is ingesting batches
of timestamped records, with each record being quite large. Individual batches
routinely contain duplicate records whose contents only differ by collection
timestamp. Ideally as new batches are ingested, duplicate records would update
the collection timestamp column, but skip updating the larger data columns.
To do this effectively, we could have a duplicate-resolution strategy that
updates individual columns to new values, effectively {{ON DUPLICATE KEY
UPDATE}} with only constants allowed as the update value. To be efficient, and
to map well to SQL, this should probably be specified once on the entire batch
instead of on individual ops.
> Add support for INSERT IGNORE
> -
>
> Key: KUDU-1563
> URL: https://issues.apache.org/jira/browse/KUDU-1563
> Project: Kudu
> Issue Type: New Feature
>Reporter: Dan Burkert
>Assignee: Brock Noland
> Labels: newbie
>
> The Java client currently has an [option to ignore duplicate row key errors|
> https://kudu.apache.org/apidocs/org/kududb/client/AsyncKuduSession.html#setIgnoreAllDuplicateRows-boolean-],
> which is implemented by filtering the errors on the client side. If we are
> going to continue to support this feature (and the consensus seems to be that
> we probably should), we should promote it to a first class operation type
> that is handled on the server side. This would have a modest perf.
> improvement since less errors are returned, and it would allow INSERT IGNORE
> ops to be mixed in the same batch as other INSERT, DELETE, UPSERT, etc. ops.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
