[infinispan-dev] Migration of data between cache stores

Tristan Tarrant ttarrant at redhat.com
Mon Sep 23 04:09:47 EDT 2013


On 09/19/2013 09:24 AM, Galder Zamarreño wrote:
> a) Bring back Infinispan 5.x classes to 6.0 to be able to read 5.x cache stores directly from 6.0.
No, we need something that is version independent (aside from the actual 
payload, for which the user is responsible).
> b) Develop some code for Infinispan 5.x to dump cache store data into a file or somewhere in a given format and then read
This is something we may want to do anyway, and it's the one that 
requires the least amount of setup.
> c) Use CLI to connect from new cluster to the old cluster and fetch all keys.
>
> I think the easiest thing would be to do c), developing a CLISourceMigrator (implements org.infinispan.upgrade.SourceMigrator) to be able to read all keys from the source embedded cluster. However, I don't see anywhere in the CLI a command that returns back all keys. Upgrade with DUMPKEYS simply calls up the local SourceMigrator.recordKnownGlobalKeyset. We'd need such a command in Infinispan 5.x and 6.x, the former to send all keys and the latter to request them.
"dumpkeys" is actually a misnomer that I want to drop eventually, since 
it was based on a limitation of HotRod which didn't provide a way to get 
all keys in a "protocol-aware" way. I'd rather call that the "source 
prepare" step.
> We'd also need a CLITargetMigrator which is pretty straightforward to do since once we have all keys, it's easy to loop through them and request them using CLI's Get operation.
>
> @Tristan, you're the rolling upgrade meister, how does this sound? If we get this right, we'd not only get cache store migration, but also embedded/library cluster rolling upgrade.
My question: how would the target connect to the source ? A temporary 
HotRod connection ? Some kind of JGroups bridge (would only work if the 
source/target use clustering) ?

Tristan



More information about the infinispan-dev mailing list