Running ngcp-check_active for each single script causes quite
some overhead, it should be enough to just check for result of
ngcp-check_active *once* and then re-use the result.
Scripts that need to be executed on all hosts (the ones with
filename *_not_replicated.up) but have been executed on sp1
already are listed as "already executed" on sp2 if the
ngcp-check-rev-applied call doesn't use the node specific check.
So generate a list of *_not_replicated.up files and run
node specific checks while generating the list of missing
revision scripts.
Without this change the following ordering is present:
3.0: http://paste.mgm.sipwise.com/show/513/
vs
trunk: http://paste.mgm.sipwise.com/show/514/
So /usr/share/ngcp-db-schema/db_scripts/base/0070_not_replicated.up
is executed between 0060_* and 0080_* on ngcp 3.0 but after 6746.up
(the last script without the _not_replicated.up suffix) and
together with all the other *_not_replicated scripts before the
next bunch of scripts (being /usr/share/ngcp-db-schema/db_scripts/diff/).
This adds a short penalty on execution time because we re-run
ngcp-check-rev-applied for the *_not_replicated scripts but it's
the only way to get it right if we want to execute all db-schema
scripts in sequential order sorted by their ID revision number.
Without this change the following ordering is present:
3.0: http://paste.mgm.sipwise.com/show/513/
vs
trunk: http://paste.mgm.sipwise.com/show/514/
So /usr/share/ngcp-db-schema/db_scripts/base/0070_not_replicated.up
is executed between 0060_* and 0080_* on ngcp 3.0 but after 6746.up
(the last script without the _not_replicated.up suffix) and
together with all the other *_not_replicated scripts before the
next bunch of scripts (being /usr/share/ngcp-db-schema/db_scripts/diff/).
This adds a short penalty on execution time because we re-run
ngcp-check-rev-applied for the *_not_replicated scripts but it's
the only way to get it right if we want to execute all db-schema
scripts in sequential order sorted by their ID revision number.
This dramatically speeds up the ngcp-update-db-schema process if
everything has been applied already or if just a few single
scripts have to be executed.
Execution times for old mode vs new (batch) mode with all present
scripts executed already:
| root@spce:~# time { /usr/sbin/ngcp-update-db-schema.orig >/dev/null ; }
|
| real 0m53.281s
| user 0m45.439s
| sys 0m5.100s
vs.
| root@spce:~# time /usr/sbin/ngcp-update-db-schema
| [ ok ] Starting MySQL database server: mysqld already running.
| Synchronizing passwords with MySQL
|
| real 0m4.096s
| user 0m1.812s
| sys 0m0.472s
The main behaviour of ngcp-check-rev-applied hasn't been changed,
it's backwards compatible (so also cfg-schema which uses
ngcp-check-rev-applied continues to work as it is), now it's just
possible to provide multiple arguments to the "--revision" option
and its output is parsed by ngcp-update-db-schema then.
So we had the 9999->10000 switch in our svn now.
Scripts >=10000 need to be executed after <=9999.
This code has never happend. Nothing to see here, move along… ٩(͡๏̯͡๏)۶
From: Michael Prokop <mprokop@sipwise.com>
The way it is now won't provide any benefit, so let's just drop it.
Let's see how we can resolve this issue in the installer...
Thanks for review + comments, Andrew
From: Michael Prokop <mprokop@sipwise.com>
We don't want to have the hostname of the deployment system
(being 'grml') when initially setting up db_schema. So let's see
whether using /etc/hostname can solve it...
From: Michael Prokop <mprokop@sipwise.com>
Victor Seva
Andreas Granig
Michael Prokop
Michael Prokop
Kirill Solomko
Andrew Pogrebennyk