* provisioning.autoprov_firmwares_data is ignored
during master-slave 3308 replication sync, as this
table can be potentially large and not used on the
proxy 3308 instance
Change-Id: I19f7feeb2f12f10abc6d6110fe691583b0d560b4
The bullsyeye-based MariaDB 10.5.9 has invalid root password set by default.
It is not possible to connect DB instance from network, the only option is
to connect DB instance through the socket.
The ngcp-installer calls ngcp-sync-db to replicate db01:3306->prx01:3308
on proxy node for the Carrier case. We have to open networking root access
temporary. ngcp-sync-db will replicate 'root' password from db01 the next moment.
Also update '1>/dev/null 2>/dev/null' to Sipwise style '&>/dev/null'.
Change-Id: I12ff71efdd8283531f03ceaf87345f3cc4e71419
After migration to bullseye, ngcp-update-db-schema is broken
inside Docker containers (Jenkins PPA tests):
> https://jenkins.mgm.sipwise.com/job/db-schema-test-db-up-docker/629/console
> ...
> + ngcp-update-db-schema -f
> mysql: unrecognized service
> Error: can't connect to local MariaDB port 3306 using '/etc/mysql/sipwise_extra.cnf'
> ...
Historically, the script ngcp-update-db-schema starts DB (if
it is not running) using the command "service mysql start".
The wrapper 'service' has to use SysV init script as
systemd unit cannot be used inside Docker.
The package mariadb provided backward compatibility symlink
in buster, but it has been removed in bullseye:
> root@11bb38c12e16:/# ls -la /etc/init.d/mysql
> ls: cannot access '/etc/init.d/mysql': No such file or directory
> root@11bb38c12e16:/# ls -la /etc/init.d/mariadb
> -rwxr-xr-x 1 root root 5966 Dec 18 20:25 /etc/init.d/mariadb
> root@11bb38c12e16:/#
The fix here is to use new/proper service name 'mariadb'.
Change-Id: Icf0d663f4a0d5256e1fc403d4fc0f3dd484ebbab
* 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
* --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>
Kirill Solomko
Alexander Lutay
Guillem Jover
Victor Seva
Andreas Granig
Michael Prokop
Michael Prokop
Andrew Pogrebennyk