aboutsummaryrefslogtreecommitdiffstats
path: root/network/config
diff options
context:
space:
mode:
authorMichele Baldessari <michele@acksyn.org>2016-06-03 12:08:18 +0200
committerDamien Ciabrini <dciabrin@redhat.com>2016-06-29 23:44:01 +0200
commit292fdf87e0fdcbd66664afc4c463f2f0e9a354fa (patch)
treef15fceb78dc0f65dab919447b2a3912439d2c343 /network/config
parent463333ccc7a33db21157db49b69c37a4b04593d9 (diff)
Dump and restore galera db during major upgrades
When the overcloud is upgraded we do a yum update of the packages. This step might introduce a newer galera version. In such a situation we need to dump the db and restore it. The high-level workflow should be the following: 1) During the main upgrade step, before shutting down the cluster we need to dump the db 2) We upgrade the packages 3) We briefly start mysql on a single node while making sure that /root/.my.cnf is briefly moved out of the way (because it contains a password) and import the data. After the import we shutdown this mysql instance 4) We let the cluster start up normally The above steps will take place in the following scenarios. Given a locally installed mariadb version X.Y.Z and release R, we will dump and restore the DB under the following conditions: A) MySqlMajorUpgrade template parameter is set to 'auto' and the upgraded package differs in X, Y *or* Z. We basically don't dump automatically if the release field changes. B) MySqlMajorUpgrade template parameter is set to 'yes' When MySqlMajorUpgrade is set to 'no', no dumping will be performed. Note that this will give a non functional upgrade if a major mariadb upgrade is taking place. Partial-Bug: #1587449 Co-Author: Damien Ciabrin <dciabrin@redhat.com> Co-Author: Mike Bayer <mbayer@redhat.com> Depends-On: I8cb4cb3193e6b823aad48ad7dbbbb227364d2a58 Depends-On: I38dcacfabc44539aab1f7da85168fe44a1b43a51 Change-Id: I374628547aed091129d0deaa29764bfc998d76ea
Diffstat (limited to 'network/config')
0 files changed, 0 insertions, 0 deletions