Difference between revisions of "SUSE Manager/migration notes"

From MicroFocusInternationalWiki
Jump to: navigation, search
(Created page with "= Notes about schema migrations = == WARNING == Incorrect manual interventions in the <code>/etc/sysconfig/rhn/schema-upgrade</code> directory have the potential of '''unrec...")
 
(Background)
Line 13: Line 13:
 
We do not upgrade the database schema automatically as part of RPM upgrades - rather we rely on users running a specific command, <code>spacewalk-schema-upgrade</code>, after RPMs are installed, to carry out the so-called “schema upgrade”.
 
We do not upgrade the database schema automatically as part of RPM upgrades - rather we rely on users running a specific command, <code>spacewalk-schema-upgrade</code>, after RPMs are installed, to carry out the so-called “schema upgrade”.
  
This command does the following: - it reads the current schema version from the database - it looks for a directory in <code>/etc/sysconfig/rhn/schema-upgrade</code> named <code>susemanager-schema-&lt;CURRENT_VERSION&gt;-to-susemanager-schema-&lt;NEWER_VERSION&gt;</code> - if one is found, SQL scripts in that directory are executed in lexicographic order - CURRENT_VERSION is set to NEWER_VERSION and a new search in <code>/etc/sysconfig/rhn/schema-upgrade</code> is made, possibly leading to a chain of upgrades
+
This command does the following:
 +
 
 +
*it reads the current schema version from the database
 +
*it looks for a directory in <code>/etc/sysconfig/rhn/schema-upgrade</code> named <code>susemanager-schema-&lt;CURRENT_VERSION&gt;-to-susemanager-schema-&lt;NEWER_VERSION&gt;</code>
 +
*if one is found, SQL scripts in that directory are executed in lexicographic order - CURRENT_VERSION is set to NEWER_VERSION and a new search in <code>/etc/sysconfig/rhn/schema-upgrade</code> is made, possibly leading to a chain of upgrades
  
 
== Major version upgrade problem ==
 
== Major version upgrade problem ==

Revision as of 10:45, 8 March 2018

Notes about schema migrations

WARNING

Incorrect manual interventions in the /etc/sysconfig/rhn/schema-upgrade directory have the potential of unrecoverable data loss and unsupportable scenarios.

Please read and understand carefully this page before altering any file or directory in the path above.

Background

SUSE Manager’s database schema changes between product versions - tables are added, dropped, restructured to accommodate for new features, optimizations, bug fixes etc.

We do not upgrade the database schema automatically as part of RPM upgrades - rather we rely on users running a specific command, spacewalk-schema-upgrade, after RPMs are installed, to carry out the so-called “schema upgrade”.

This command does the following:

  • it reads the current schema version from the database
  • it looks for a directory in /etc/sysconfig/rhn/schema-upgrade named susemanager-schema-<CURRENT_VERSION>-to-susemanager-schema-<NEWER_VERSION>
  • if one is found, SQL scripts in that directory are executed in lexicographic order - CURRENT_VERSION is set to NEWER_VERSION and a new search in /etc/sysconfig/rhn/schema-upgrade is made, possibly leading to a chain of upgrades

Major version upgrade problem

When dealing with major version upgrades, directories in /etc/sysconfig/rhn/schema-upgrade have to cover all possible pairs of versions. For example, users should be able to migrate from any 3.0 version to the latest 3.1 version at any point in time (this example is followed from now on, but the reasoning is general).

This is unfortunately not always possible, particularly in cases when a 3.1 minor version is released before a 3.0 minor version. In that case packages in 3.1 might not contain schema migrations from the very latest 3.0 version, simply because they were published before the exact 3.0 version number was attributed.

In those rare cases where users have to migrate the very latest 3.0 version to 3.1 and the 3.1 version does not yet contain a valid schema upgrade script for that version, a workaround described below is recommended.

Workaround

The workaround consists in creating an empty directory in /etc/sysconfig/rhn/schema-upgrade, specifically from the version of 3.0 the user is upgrading from to the very first 3.1 version: 3.1.0.

This results in spacewalk-schema-upgrade applying any pending 3.0 upgrade first, then to start applying all 3.1 schema upgrades from the first to the last.

Incorrectly-applied workaround

Applying an incorrect workaround, ie. creating the wrong directory, can have disastrous results.

There was a case where the user was migrating from 3.0.22 to 3.1.12, and an empty directory was created with this name:

/etc/sysconfig/rhn/schema-upgrade/susemanager-schema-3.0.22-to-susemanager-schema-3.1.12

Later on the user tried to migrate to 3.1.15 and that failed because changes introduced from 3.1.0 had not been applied.

Recommendations

If at all possible, avoid any manual intervention in /etc/sysconfig/rhn/schema-upgrade. If you think you really need to do so, please ask for a confirmation to the development team before proceeding.