powerman / narada Goto Github PK

Because of this commands in migrate like:

mysql           .release/newtable.sql
rollback_mysql  .release/newtable.undo.sql

do not interrupt migration.

At the moment narada-restore keeps only .release/, .backup/ and .lock*, but it will be useful to keep some user-defined files too.

Maybe keep files in var/run/ or run/ (but this will require changes in narada conventions)?

It may make sense to make it possible to run something after RESTORE - like narada-start-services & to not wait for 1 minute after narada-install until services will be started again from cron.

@nsavin Is there any reasons why we should include .release/ in backups?

32 Configuring Narada-v2.2.0 ... OK
33 ==> Found dependencies: Path::Tiny, Test::MockModule, Perl6::Export::Attrs, App::migrate, Test::CheckManifest, DBI, Test::Differences, Test::Exception, DBD::mysql, Pod::Coverage, App::powerdiff, Test::Outpu t, Test::Pod::Coverage, Test::Perl::Critic, Test::Pod, Log::Fast, File::Copy::Recursive

Narada requires DBD::mysql which in turn requires MySQL binaries ("sudo apt-get install libmysqlclient-dev" in Debian). Could we remove this dependency?

My project does not use MySQL so it is needless to have it installed in the system. Maybe we could move it beyond an eval, e.g. eval { require DBD::mysql; }

…because they're full of bugs like https://bugs.gentoo.org/show_bug.cgi?id=546294

Try to create incr.tar, but then, after releasing exclusive lock, just repack in temporary directory:

• unpack full.tar
• unpack incr.tar
• pack again into new, incremental but non-concatenated full.tar

Maybe this can be optimized by keeping temporary directory which match current full.tar?

@nsavin How about a pull request for this feature? 😄

Like using GitHub releases to upload/download releases from .release/ and avoid adding this directory to repo. This should help for languages like Go which releases contains large binaries and this significantly increase size of repo.

Probably it should be configurable/plugin feature, to let user decide where releases should be stored.

cc: @nsavin

• если проект не был активен (narada-setup-* не вызывали), то при
  восстановлении бэкапа вызывать narada-setup-* нельзя
  • насчёт narada-shutdown|start-services не ясно
• если проект был активен, то вызывать narada-setup-* нужно, причём
  примерно так, как реализовано сейчас (избегая промежуточного --clean
  чтобы не пропустить какие-нить события вроде писем)
• что делать если проект был активен частично: cron да, mysql нет?
  • и что делать, если текущая версия активна, но не использует mysql, а
    предыдущая, восстанавливаемая из бэкапа, использовала mysql?

Useful doc: https://wiki.ubuntu.com/DashAsBinSh

• tar x … --exclude './.lock*' will remove .lock* files which wasn't exists while backup
  • this means there is no way to protect new lock files in project root directory from being removed while restoring backup
• tar x … --exclude './tmp/*' will remove tmp/* files which wasn't exists while backup
  • tar x … --exclude './tmp' will not create tmp/ if it isn't exists

Is there any good enough alternatives for tar?

It both require but not mention in Makefile.PL PadWalker (bug filed), and also result in this error:

t/build/migrate.t .. 1/1 # Narada::Lock does not export: exclusive_lock unlock_new shared_lock unlock