[jira] [Commented] (ACCUMULO-3598) Address varied file versions by servers over RPC layer

["Josh Elser (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/ACCUMULO-3598?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14359594#comment-14359594 ] 

Josh Elser commented on ACCUMULO-3598:
--------------------------------------

I was thinking about how to address this. The approach I came up with was to make two new znodes: one to track the rfile version and another to track the wal version. The master would be the coordinator that updates the value for these nodes and tservers could watch them. When the tserver sees the change, they can flip over to writing the newer version. The async-nature of the propagation via ZK is unimportant because these new servers should also be able to read the old files.

This approach is, however, predicated on the assumption that we can construct a writer specific for a version (e.g. {{RFile.newWriter(8)}}). This would let us provide a simple API through the master to coordinate this, akin to a {{hdfs dfsadmin -finalizeUpgrade}}. After the rolling restart/upgrade of all of the nodes is complete, the servers can be switched over to using the new file formats with a single API call.

> Address varied file versions by servers over RPC layer
> ------------------------------------------------------
>
>                 Key: ACCUMULO-3598
>                 URL: https://issues.apache.org/jira/browse/ACCUMULO-3598
>             Project: Accumulo
>          Issue Type: Sub-task
>          Components: tserver
>            Reporter: Josh Elser
>             Fix For: 1.7.0
>
>
> There's an issue of handling newer versions of RFile and WALs in the middle of a rolling restart.
> 1. Server1 is restarted as the new version
> 2. Server1 writes some new data
> 3. Server1 dies
> 4. Server2 (still old version) gets the tablets from Server1
> We need to ensure that there is control to limit the new software from writing out new versions of persistent files while there are still old versions of the software participating in the instance. It's similar to finalizing an upgrade: after we're sure that all of the servers have been upgraded and are functioning well, we can flip them over to using new messages/serialization that the old versions aren't aware of.
> This problem gets much easier after we adopt Thrift/PB for serializing things because both of those can naturally read newer versions of messages they know about, ignoring the new fields.
> Ideally, we should define an API which rolling restart (ACCUMULO-1454) can leverage, but there are many ways we could go about the "feature".



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)