tarantool / migrate

Migration framework from Tarantool 1.5 to 1.6
1 stars 0 forks source link

Support 1.5 Replication protocol #2

Open bigbes opened 8 years ago

bigbes commented 8 years ago

Do it on top of tnt_rpl and tnt_nbio (non-blocking IO using coio_wait function).

To implement:

Totktonada commented 4 years ago

NB: There is replication-support branch (dda8c86501a52ca63e9c7c39e687eeb7eed2e2bd). Its status is unclear.

@bigbes said that it segfaults after a time and that there was a guess that it is due to a leak in LuaJIT. It is not clear too.

Totktonada commented 4 years ago

We recently meet with @Mons, @orchaton, @alyapunov, @ligurio and @kyukhin regarding upgrade from tarantool 1.5 to 1.6+. Part of meeting notes that are relevant to this issue:

  • Support replication from a remote instance using iproto.
    • It solves several problems:
    • Tarantool 1.5 already holds more than 1/2 memory of a machine for memtx data / indices and so. This instance cannot be replicated to the 1.10 instance on the same machine.
    • Tarantool 1.5 and 1.6+ conflicts by paths when installed from a package.
    • There are known peculiars:
    • Tarantool 1.5 replication protocol does not support transferring of an initial snapshot, so it should be moved manually to a target machine. We should describe the process to replicate from a remote instance in README.
    • Tarantool 1.5 does not create a new xlog when a new snapshot is created, but continue to write the old one (until operations count will exceed a limit). It also don't remove old xlog files automatically, so it is manual action. We should highlight that an xlog file from which we're replicated should not be removed in the README.
    • There is https://github.com/tarantool/migrate/issues/2
Totktonada commented 4 years ago

A bit more:

  • Verify that lsn of an operation is <lsn of the previous one + 1>.
    • Someone (Mons or Vlad G., don't remember) said that replication in 1.5 is unstable and recommends to verify lsn numbers on the 1.6+ side.
    • It worth to provide an option like 'force_recovery' to continue despite possible inconsistency, but report an error and stop replication by default.
    • Looks as the part of iproto replication support feature request.
    • Added to https://github.com/tarantool/migrate/issues/2
Totktonada commented 3 years ago

@orchaton said he has another replicator from 1.5 to 1.10+, which uses the 1.5 binary protocol and so it can close this demand. So we'll wait for his results and if everything will be fine, we'll not doing the work twice and implement it here too.

If we'll not implement it, let's add a link to the alternative migrator and briefly describe cons and pros.