MySQL 管理器重构¶

存在许多不同版本的 MySQL，它们在不同程度上存在差异。本蓝图建议为基于 MySQL 的数据存储创建一个类结构，以避免共享功能和能力的代码重复。

预计从这项工作中获得的经验将适用于未来为 MongoDB 和 PostgreSQL 等系统提供差异化的工作。

https://blueprints.launchpad.net/trove/+spec/mysql-manager-refactor

问题描述¶

近年来，出现了许多 MySQL 的分支版本，与 MySQL 社区版 (CE) 的差异程度各不相同。常用的 MySQL 变体包括 Percona 和 MariaDB。还存在特定于某个变体的专用版本，例如 MariaDB 的 Galera 或 MySQL Cluster (NDB)。尽管存在差异，但这些变体之间有很多共同之处。因此，为每个变体完全独立的 datastore 实现会导致代码重复，从而导致维护困难，并可能让期望在不同系统上以相同方式处理通用功能的运维人员感到困惑。

Openstack Trove 将受益于 MySQL 管理器的重构，从而更一致地支持类似 MySQL 的系统，简化代码维护（随着变体的演进），并能够提供差异化功能。也可以相对容易地引入新的变体。

提议的变更¶

现有的 MySQL datastore 代码位于 trove/guestagent/datastore/mysql。该 datastore 实际上已经充当了一种超级类，Percona 和 MySQL datastore 都指向相同的管理代码。如果底层 MariaDB 实例被视为 MySQL，则支持 MariaDB。

本蓝图的核心是将现有的 MySQL 管理器代码的大部分移动到一组新的抽象类中，MySQL、Percona 和 MariaDB datastore 的子类将从这些类继承。

成熟度感知型重组

基础 mysql 代码将保留在当前的 mysql datastore 目录中。这将导致

在 trove/guestagent/datastore/mysql 目录中创建新的 manager 和 service 模块的基础实现
创建显式的 Percona 和 MariaDB datastore，其实现类从基础 MySQL 继承。

文件和目录结构将从

trove/guestagent/datastore/mysql/manager.py
trove/guestagent/datastore/mysql/service.py

变为

trove/guestagent/datastore/mysql/manager_base.py
trove/guestagent/datastore/mysql/service_base.py
trove/guestagent/datastore/mysql/manager.py
trove/guestagent/datastore/mysql/service.py
trove/guestagent/datastore/experimental/mariadb/manager.py
trove/guestagent/datastore/experimental/mariadb/service.py
trove/guestagent/datastore/experimental/percona/manager.py
trove/guestagent/datastore/experimental/percona/service.py

这种方法的好处是减少了对基础代码成熟度级别的潜在混淆。但是，它的组织方式不够清晰：MySQL CE 被视为一个基础系统和一个实现 datastore。

将对 MySQL 管理器代码进行一次遍历，以识别应设为抽象的方法。然后，这些方法将被“向下”移动到子类中。

本蓝图不尝试创建优化的 MariaDB 或 Percona datastore，而是为它们的创建奠定基础。

Service 类依赖注入

service.py 模块包含许多类，例如 MySqlAppStatus，这些类在 manager.py 模块中使用。当前它们紧密耦合：mysql 管理器具有每个类的显式导入。

为了能够任意扩展这些类以用于不同的 datastore，并消除紧密耦合，旧的引用将被重构为类属性，这些属性将由具体的 manager 类注入。

策略整合

当前不包含在本重构的范围内，但一个重要的未来考虑因素是相关的策略，这些策略在不同的变体之间也可能存在差异。例如，将复制策略中的一些或全部逻辑带入 datastore 子树以提供差异化可能是有意义的。

配置¶

指向完全限定类名的 guest agent 配置文件选项，例如

datastore_registry_ext =
  mysql:trove.guestagent.datastore.mysql.manager.Manager,
  percona:trove.guestagent.datastore.mysql.manager.Manager

需要指向新的类名，例如

datastore_registry_ext =
  mysql:trove.guestagent.datastore.mysql.manager.Manager,
  percona:trove.guestagent.datastore.percona.manager.Manager,
  mariadb:trove.guestagent.datastore.experimental.mariadb.manager.Manager

数据库¶

无预期，确认即可。

Python API¶

无。

CLI (python-troveclient)¶

无。

公共 API¶

无。

公共 API 安全¶

无。

内部 API¶

无。

Guest Agent¶

行为应保持不变，但代码的位置会发生变化。

备选方案¶

Proposed Change 部分讨论了两种替代方案。

实现¶

负责人¶

主要负责人

Launchpad/IRC: atomic77

Email: atomic@tesora.com

里程碑¶

完成目标里程碑

liberty-1

工作项¶

重组代码
创建 Percona 和 MariaDB datastore 的 stub 实现，这些实现从基础 MySQL 类继承。
检查 MySQL datastore 实现，以确定抽象方法的初始候选对象。将其向下移动并在三个 datastore 实现中重新实现。
编写额外的集成测试

升级影响¶

与源代码树布局的任何更改一样，运维人员必须小心确保 guest agent 上的代码更新与配置文件更新同步。这仅对最终希望利用新的优化的 Percona、MariaDB 等 manager 的运维人员来说是一个问题，因为 MySQL CE manager 的位置将保持向后兼容。

依赖项¶

无。

测试¶

应添加额外的测试以确保子类化正常工作，例如，确保某些 Percona 特定的代码不会在 MySQL datastore 上运行等。

文档影响¶

应更新文档，以告知运维人员可以添加到 guestagent 配置文件中的 datastore 实现的新位置。

参考资料¶

一个相关的蓝图是 experimental-datastores [1]，因为它会影响 datastore 实现的组织方式，即基于成熟度级别进行组织。

[1] https://blueprints.launchpad.net/trove/+spec/experimental-datastores

MySQL Manager 重构