快捷導(dǎo)航

Openstack 使用migrate進行數(shù)據(jù)庫升級實現(xiàn)方案詳細(xì)介紹

更新時間：2016年12月04日 15:17:27 作者：Sylvernass

這篇文章主要介紹了Openstack 使用migrate進行數(shù)據(jù)庫升級詳細(xì)介紹的相關(guān)資料,數(shù)據(jù)庫表或者增加字段等是必然的事情，如何比較容易的進行這些數(shù)據(jù)庫升級的適配和管理，這里提供實現(xiàn)方法，需要的朋友可以參考下

Openstack 使用migrate進行數(shù)據(jù)庫升級實現(xiàn)方案詳細(xì)介紹

OpenStack中隨著版本的切換，新版本加入一些數(shù)據(jù)庫表或者增加字段等是必然的事情，如何比較容易的進行這些數(shù)據(jù)庫升級的適配和管理，這里就要用到oslo_db中的migrate了，這里以為M版本的heat為例，講解一下migrate管理db的原理。

我們使用migrate需要用到的主要包含以下兩部分：1.versions里面的為版本號+數(shù)據(jù)庫適配腳本；2.migrate.cfg為migrate需要用到的配置文件，兩部分的命名是固定的。

使用migrate進行數(shù)據(jù)庫升級非常簡單，heat這邊提供了heat-manage db_sync, db_version的命令用來升級db以及查看當(dāng)前db的版本號，這里以執(zhí)行heat-manages db_sync，看下migrate的過程。



def db_sync(engine, version=None): 
  path = os.path.join(os.path.abspath(os.path.dirname(__file__)), 
            'migrate_repo') 
  return oslo_migration.db_sync(engine, path, version, 
                 init_version=INIT_VERSION)

heat代碼的入口在這里，需要傳入engine用來連接db，version為我們需要升級到的版本，這里沒有傳，可以看到heat這邊是直接使用oslo_migrate的db_sync方法，我們看下三方庫中的這個方法。

def db_sync(engine, abs_path, version=None, init_version=0, sanity_check=True): 
  """Upgrade or downgrade a database. 
 
  Function runs the upgrade() or downgrade() functions in change scripts. 
 
  :param engine:    SQLAlchemy engine instance for a given database   //連接數(shù)據(jù)庫 
  :param abs_path:   Absolute path to migrate repository.         //migrate倉庫的絕對路徑 
  :param version:   Database will upgrade/downgrade until this version. //需要升級或者降級到的版本號，如果不傳則默認(rèn)升級到最新版本 
             If None - database will update to the latest 
             available version. 
  :param init_version: Initial database version               //數(shù)據(jù)庫的初始版本號，會以該初始版本為起點升級 
  :param sanity_check: Require schema sanity checking for all tables    //合理性檢查 
  """ 
 
  if version is not None: 
    try: 
      version = int(version) 
    except ValueError: 
      raise exception.DBMigrationError(_("version should be an integer")) 
 
  current_version = db_version(engine, abs_path, init_version) 
  repository = _find_migrate_repo(abs_path) 
  if sanity_check: 
    _db_schema_sanity_check(engine) 
  if version is None or version > current_version: 
    migration = versioning_api.upgrade(engine, repository, version) 
  else: 
    migration = versioning_api.downgrade(engine, repository, 
                       version) 
  if sanity_check: 
    _db_schema_sanity_check(engine) 
 
  return migration

代碼很清晰，簡潔。可以看到，整個過程就是先查詢下當(dāng)前db的版本，然后聲明一個migrate倉庫示例，對db做合理性檢查（主要是針對mysql），然后根據(jù)傳入的version和當(dāng)前的version決定是升級或者降低，最后再次檢查，整個migrate就完成了。

首先是查詢當(dāng)前數(shù)據(jù)庫的版本，



def db_version(engine, abs_path, init_version): 
  """Show the current version of the repository. 
 
  :param engine: SQLAlchemy engine instance for a given database 
  :param abs_path: Absolute path to migrate repository 
  :param init_version: Initial database version 
  """ 
  repository = _find_migrate_repo(abs_path) 
  try: 
    return versioning_api.db_version(engine, repository) 
  except versioning_exceptions.DatabaseNotControlledError: 
    meta = sqlalchemy.MetaData() 
    meta.reflect(bind=engine) 
    tables = meta.tables 
    if len(tables) == 0 or 'alembic_version' in tables: 
      db_version_control(engine, abs_path, version=init_version) 
      return versioning_api.db_version(engine, repository) 
    else: 
      raise exception.DBMigrationError( 
        _("The database is not under version control, but has " 
         "tables. Please stamp the current version of the schema " 
         "manually."))

首先是根據(jù)傳入的絕對路徑，構(gòu)造一個倉庫對象的示例，這里比較關(guān)鍵，初始化方法如下，可以看到我們前面提到migrate.cfg和versions就是在這里被使用的，而且名字也是固定的，必須為migrate.cfg和versions。

class Repository(pathed.Pathed): 
  """A project's change script repository""" 
 
  _config = 'migrate.cfg' 
  _versions = 'versions' 
 
  def __init__(self, path): 
    log.debug('Loading repository %s...' % path) 
    self.verify(path) 
    super(Repository, self).__init__(path) 
    self.config = cfgparse.Config(os.path.join(self.path, self._config)) 
    self.versions = version.Collection(os.path.join(self.path, 
                           self._versions)) 
    log.debug('Repository %s loaded successfully' % path) 
    log.debug('Config: %r' % self.config.to_dict())

這里會驗證我們傳入的path下面是否存在versions和migrate.cfg，因此我們的代碼目錄結(jié)構(gòu)也必須按照這個放。self.config主要是用來管理migrate.cfg的配置，self.versions主要用來管理如何升級，repository對象另外還包含3個比較重要的屬性，latest：最新的版本（versions中版本號最大的），這里是73，version_table：用來記錄和管理migrate版本號的數(shù)據(jù)庫表，這里是migrate_version，id用來存放我們管理的數(shù)據(jù)庫標(biāo)示，這里是heat，后兩項都是從數(shù)據(jù)庫里面取。

@property 
  def latest(self): 
    """API to :attr:`migrate.versioning.version.Collection.latest`""" 
    return self.versions.latest 
 
  @property 
  def version_table(self): 
    """Returns version_table name specified in config""" 
    return self.config.get('db_settings', 'version_table') 
 
  @property 
  def id(self): 
    """Returns repository id specified in config""" 
    return self.config.get('db_settings', 'repository_id')

回到之前的代碼

try: 
  return versioning_api.db_version(engine, repository) 
except versioning_exceptions.DatabaseNotControlledError: 
  meta = sqlalchemy.MetaData() 
  meta.reflect(bind=engine) 
  tables = meta.tables 
  if len(tables) == 0 or 'alembic_version' in tables: 
    db_version_control(engine, abs_path, version=init_version) 
    return versioning_api.db_version(engine, repository) 
  else: 
    raise exception.DBMigrationError( 
      _("The database is not under version control, but has " 
       "tables. Please stamp the current version of the schema " 
       "manually."))

這里會根據(jù)數(shù)據(jù)庫引擎和剛才的repository實例對象獲取當(dāng)前數(shù)據(jù)庫的版本號，其實就是從migrate本身所在數(shù)據(jù)表中去查找當(dāng)前的版本號（version_version），假如是第一次使用migrate，由于還沒有建立migrate_version表，所以引發(fā)異常。這里會去查一下當(dāng)前數(shù)據(jù)庫中的所有數(shù)據(jù)表，如果已有其他數(shù)據(jù)庫表，則會引發(fā)DBMigrationError的異常，因為migrate必須在建立其他數(shù)據(jù)表之前先建立才能管控所有的數(shù)據(jù)表，假如我們之前沒有使用migrate機制但是想在后面的db控制中使用起來，這里有2個思路：手動插入migrate_version數(shù)據(jù)表并配置合適的版本或者手動插入alebic_version。

繼續(xù)往下面看，如果是第一次使用migrate，



db_version_control(engine, abs_path, version=init_version)

會建立migrate_version，并設(shè)置合適的初始值，也就是傳入的init_version，后續(xù)的數(shù)據(jù)庫升級等操作就可以通過migrate管控起來了。migrate_version表建立起來后，就回到了最初的流程，根據(jù)我們db_sync傳入的版本號和當(dāng)前的版本號，migrate會執(zhí)行versions里面每個版本的upgrade（）方法直至升級完成并更新migrate_version中的版本號。

使用migrate的好處在于，可以很方便的集中記錄和管理每次對數(shù)據(jù)庫的變動，在后續(xù)升級過程中，一鍵式完成對應(yīng)的適配操作，非常方便，并且不會出現(xiàn)重復(fù)增加字段等操作，在開發(fā)過程中，我們只要知道了migrate的原理，就能很方便的使用起來了。

感謝閱讀，希望能幫助到大家，謝謝大家對本站的支持！

您可能感興趣的文章: