-
Notifications
You must be signed in to change notification settings - Fork 62
Migration
Upgrades are never an exact science, and generally are not recommended unless you have the time/skills to perform them if/when things fail. We do our best to provide the utilities and doc necessarily to cover edge cases, if something goes horribly bad, it might make more sense to start fresh with a new installation and new data. This is a learning process for the project and we don't currently have the resources to debug problems that might occur during a database upgrade between versions.
That being said, as long as you follow the directions carefully, backup your archive table (external usb-drives can be handy), you should be able to recover from a failed upgrade with out losing everything.
If you do lose everything, ... it's not the end of the world, within a few weeks, your shinny new v2 instance will have lots of data in it to make lemonade with. :)
There are no "in-place" upgrades from v1 to v2, a new host must be created.
CIFv2 changes the way we've generated API tokens from a "UUID" to a random SHA1 hash. That said, it's HIGHLY RECOMMENDED that you skip exporting and importing your old v1 tokens and generate new ones. If you choose to import your old tokens, we've developed a helper export utility for v1 that exports the old tokens as cleanly as possible into JSON compatible with the v2 cif-tokens --import
flag (via STDIN).
- on your v1 instance
$ cif_apikeys_export > tokens.json
- on your v2 instance:
$ cif-tokens --import tokens.json
The data migration is a little more complicated. Effectively we're taking data from a postgres database and re-inserting it to an elastic-search database. Along with that, we're re-mapping some of the old style fields to our new v2 schema. We've created some more helper utilities to aid in the process.
- setup a new CIFv2 host
- be sure the new v2 host has psql (tcp/5432) to the v1 database host
- be sure to use a token generated from cif-tokens that has access to all groups on the new host (if you're using more than the default 'everyone' group, otherwise the root@localhost token will work OK)
- run the migration tool (this will take a few days depending how much data you have):
$ sudo aptitude install -y postgresql-common libpq-dev postgresql-client-9.3 autoconf
$ cd massive-octo-spice/v1migration
$ sudo cpanm DBD::Pg ZMQ::FFI@0.17 Compress::Snappy --force
$ sudo cpanm --installdeps . # be sure to install cpanm if it's not on this box
$ perl -I../src/lib -Ilib bin/migrate-data.pl -h
$ perl -I../src/lib -Ilib bin/migrate-data.pl --threads 4 --psql-host 192.168.1.1 --es-token XXXXXXX
This should migrate the data over in stages, while keeping track of what records it's written in the journal located at /tmp/cif-migrate.journal
. That way, if the tool fails, or something happens, it will start where it left off.