* determine the master db node name to use
for ngcp-sync-db master-slave replication restoration
if the CENTRAL_DBHOST is set by default to db01 only.
if the current nodename ends with "a" then db01a is used,
otehrwise db01b is used as the master host. that is
to make sure that during the upgrade the correct "side"
is used to replicate the data from and avoid lossy
statements that break replication.
Change-Id: I1a51bd0d975390d9269ef5208ce8275f9e055a1f
(cherry picked from commit 1cfafba736)
* --init-replication is required now for the central-db
because it uses multiple sources and they need to be
readjusted after the data sync
Change-Id: I10c12d479dbe7d73e6e489d3aa9ab37b7216af54
We are in the process of removing the obsolete init scripts, so trying
to use them directly will make these operations not work at all.
Change-Id: Ifff400388a947294ca661b3b8bad793b755ee830
* host and port by ngcp-sync-db is now used from
/etc/default/ngcp-db to ensure the correct R/O instance db
Change-Id: Ib7d9dde15cc4e5fa4ca95bb2d5b6ea508e12f89a
* ngcp database contains a 'timezone' table that
is used in replicated billing database
and therefore, needs to be also replicated
Change-Id: Iaaa23ff8cece68f4e9944a690bfc47c243d64f9f
We suppress some warning here to mark the repo as clean
while further cleanup can be done to remove some labels
'shellcheck disable'.
The first step here is to prevent new errors appearing.
Change-Id: I23ca9dd6fdf80bab6b9ec465dd4a53983e34a52a
* extra ngcp-sync-db options in AUTOMATED_INSTALL_MODE
* ngcp-sync-db is invoked only once now (after all revisions)
Change-Id: I6db3c29f186e1a61df1ccce17b0a646efaa1b055
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>
Kirill Solomko
Alexander Lutay
Guillem Jover
Victor Seva
Andreas Granig
Michael Prokop
Michael Prokop
Andrew Pogrebennyk