[
https://issues.apache.org/jira/browse/KUDU-2396?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrew Wong updated KUDU-2396:
------------------------------
Description:
I recently migrating some machines such that the host/port pairs on disk in the
cmeta and WALs no longer matched their actual location. One solution around
this was to use DNS aliasing to point the old machines to the new machines e.g.
putting something like the following into the /etc/hosts files on all of the
new machines:
{quote}new.tserver.ip.1 old.tserver.1.com
new.tserver.ip.2 old.tserver.2.com
new.tserver.ip.3 old.tserver.3.com
new.tserver.ip.4 old.tserver.4.com
{quote}
In cases where this is not possible (if, say, the new machines are hosting
services that require talking to the old machines), the remaining workaround
would be to rewrite the host/ports on disk. For the cmeta, this is as simple as
rewriting some protobuf container files with `kudu pbc edit`, but for the
pending config changes in the WALs, this is not the case, since we currently
have no tooling to rewrite WAL segments. As such, tooling to edit the WALs as
we have for pbc files would be nice.
Of course, solving KUDU-418 would make this tooling unnecessary for this use
case, but this is at least an option to make the larger problem more easily
handleable in the short term.
was:
I recently migrating some machines such that the host/port pairs on disk in the
cmeta and WALs no longer matched their actual location. One solution around
this was to use DNS aliasing to point the old machines to the new machines e.g.
putting something like the following into the /etc/hosts files on all of the
new machines:
{quote}new.tserver.ip.1 old.tserver.1.com
new.tserver.ip.2 old.tserver.2.com
new.tserver.ip.3 old.tserver.3.com
new.tserver.ip.4 old.tserver.4.com{quote}
In cases where this is not possible (if, say, the old machines are hosting new
Kudu services at the existing ports, etc.), the remaining workaround would be
to rewrite the host/ports on disk. For the cmeta, this is as simple as
rewriting some protobuf container files with `kudu pbc edit`, but for the
pending config changes in the WALs, this is not the case, since we currently
have no tooling to rewrite WAL segments. As such, tooling to edit the WALs as
we have for pbc files would be nice.
Of course, solving KUDU-418 would make this tooling unnecessary for this use
case, but this is at least an option to make the larger problem more easily
handleable in the short term.
> Tool to edit host/port for pending config changes in the WAL after machine
> migration
> ------------------------------------------------------------------------------------
>
> Key: KUDU-2396
> URL: https://issues.apache.org/jira/browse/KUDU-2396
> Project: Kudu
> Issue Type: New Feature
> Components: log, ops-tooling
> Reporter: Andrew Wong
> Priority: Major
>
> I recently migrating some machines such that the host/port pairs on disk in
> the cmeta and WALs no longer matched their actual location. One solution
> around this was to use DNS aliasing to point the old machines to the new
> machines e.g. putting something like the following into the /etc/hosts files
> on all of the new machines:
> {quote}new.tserver.ip.1 old.tserver.1.com
> new.tserver.ip.2 old.tserver.2.com
> new.tserver.ip.3 old.tserver.3.com
> new.tserver.ip.4 old.tserver.4.com
> {quote}
> In cases where this is not possible (if, say, the new machines are hosting
> services that require talking to the old machines), the remaining workaround
> would be to rewrite the host/ports on disk. For the cmeta, this is as simple
> as rewriting some protobuf container files with `kudu pbc edit`, but for the
> pending config changes in the WALs, this is not the case, since we currently
> have no tooling to rewrite WAL segments. As such, tooling to edit the WALs as
> we have for pbc files would be nice.
> Of course, solving KUDU-418 would make this tooling unnecessary for this use
> case, but this is at least an option to make the larger problem more easily
> handleable in the short term.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
