DB 支持¶
https://blueprints.launchpad.net/vitrage/+spec/db-support
Vitrage 需要持久化 DB。主要原因是历史记录和高可用性，但持久化 DB 还有其他用途，例如保存已注册的 REST 通知接收者，以及使用 DB 功能提高性能。我们将使用 sqlalchemy 进行 DB 管理，与 Nova、Heat、Aodh 和其他项目相同。
问题描述¶
Vitrage 应该支持持久化 DB 管理。
提议的变更¶
开发将分几个阶段进行。为了加快 Vitrage 历史记录/HA/Vitrage 通知功能的开发，第一阶段将只开发基本的 sqlalchemy 支持。
注意：sqlalchemy 实现的一个很好的例子可以在以下链接找到：
https://github.com/openstack/aodh/blob/master/aodh/storage/impl_sqlalchemy.py
vitrage.conf 中的基本配置
# 用于连接数据库的 SQLAlchemy 连接字符串。
# 示例
# connection = mysql://root:pass@127.0.0.1:8999/vitrage
#connection = <None>
# 用于 MySQL 会话的 SQL 模式。此选项（包括默认值）会覆盖任何服务器设置的 SQL 模式。要使用服务器配置设置的任何 SQL 模式，请将其设置为空值。示例：mysql_sql_mode=
# (字符串值)
# (string value)
# (string value)
# 附加模式及其功能
# https://dev.mysqlserver.cn/doc/refman/5.7/en/sql-mode.html#sql-mode-combo
#mysql_sql_mode = TRADITIONAL
# 闲置 SQL 连接被回收前的超时时间。（整数值）
#idle_timeout = 3600
# 池中保持打开的 SQL 连接的最小数量。（整数值）
#min_pool_size = 1
# 池中保持打开的 SQL 连接的最大数量。将值设置为 0 表示没有限制。（整数值）
# 0 表示无限制。（整数值）
#max_pool_size = 5
# 启动期间数据库连接重试的最大次数。设置为 -1 表示无限重试。（整数值）
# 指定无限重试计数。（整数值）
#max_retries = 10
# 打开 SQL 连接重试之间的间隔。（整数值）
#retry_interval = 10
# 如果设置，将此值用于 SQLAlchemy 的 max_overflow。（整数值）
#max_overflow = 50
# SQL 调试信息的详细程度：0=无，100=所有。（整数
# 值）
# 最小值：0
# 最大值：100
#connection_debug = 0
# 将 Python 堆栈跟踪作为注释字符串添加到 SQL 中。（布尔值）
#connection_trace = false
# 如果设置，将此值用于 SQLAlchemy 的 pool_timeout。（整数值）
#pool_timeout = <None>
# 启用连接丢失时实验性地使用数据库重新连接。
# (布尔值)
#use_db_reconnect = false
# 数据库事务重试之间的秒数。（整数值）
#db_retry_interval = 1
# 如果为 True，则增加数据库操作重试之间的间隔，直到
# db_max_retry_interval。（布尔值）
#db_inc_retry_interval = true
# 如果设置了 db_inc_retry_interval，则数据库操作重试之间的最大秒数。（整数值）
# 数据库操作。（整数值）
#db_max_retry_interval = 10
# 在引发错误之前，连接错误或死锁错误情况下的最大重试次数。设置为 -1 表示无限重试。（整数值）
# 在引发错误之前。
#db_max_retries = 20
步骤 1¶
构建一个基本的 sqlalchemy 实现，用于连接到 DB，在 DB 中创建 Vitrage 模式和所需的表（来自 Vitrage 历史记录规范和 Vitrage httppost 注册规范）。每个开发人员都应该将自己的表添加到模式并进行测试。
模式和表应每次 Vitrage 加载时从 Vitrage 动态创建。Vitrage 将测试数据库表是否存在，如果不存在，则使用“模型”数据表示创建它们。在第一阶段不需要测试现有表的有效性甚至修复它们。
Cinder 数据模型示例：https://github.com/openstack/cinder/blob/master/cinder/db/sqlalchemy/models.py
创建将在表上执行硬编码 CRUD 的 DAO。
步骤 2¶
使用 alembic 进行升级/版本控制。
通用 sql 支持。
大型查询（例如所有实体图或事件表）的分页。
备选方案¶
今天不行。
数据模型影响¶
这个整体设计对数据模型影响巨大。
REST API 影响¶
无
安全影响¶
无
流水线影响¶
无
其他最终用户影响¶
无
性能/可扩展性影响¶
应应用适当的索引，并根据开发过程中的性能测试，将多表数据拆分为较小的索引表，以提高数据轮询性能。
其他部署者影响¶
无
开发者影响¶
无
实现¶
负责人¶
主要负责人：danoffek. alexey_weyl。
工作项¶
创建一个基本的 SQLAlchemy 实现来连接到 DB。
为事件和其他表创建数据模型。
为事件存储创建简单的 CRUD 方法。
CRUD 模板
按“测试”中说明进行测试。
未来生命周期¶
参见“步骤 2”
依赖项¶
无
测试¶
单元测试
数据选择查询
数据更新
创建带索引的表
（不应在网关或定期运行）在大型表数据上进行性能测试，每秒多次插入，持续一小时。
Tempest 测试：每个开发人员都应该创建自己的 DB tempest 测试。例如：创建告警/资源事件，然后轮询系统。如果数据未正确存储在事件表中，则应发出错误。
文档影响¶
DB 配置应记录在一个 .rst 文件中，并且应从 https://github.com/openstack/vitrage/blob/master/doc/source/installation-and-configuration.rst 链接到该文件
