Canvas LMS开发指南:使用GuardRail实现数据库读写分离
canvas-lms The open LMS by Instructure, Inc. 项目地址: https://gitcode.com/gh_mirrors/ca/canvas-lms
什么是GuardRail
GuardRail是Canvas LMS项目中一个强大的数据库配置工具,它允许开发者为特定代码块激活不同的数据库配置。在Canvas的实际应用中,最常见的场景是将读查询(SELECT)操作分流到副本(secondary)数据库上,从而减轻主数据库的负载压力。
为什么需要GuardRail
在开发过程中,当我们尝试将读查询分流到副本数据库时,必须确保这些操作不会意外地执行写入操作。GuardRail提供了以下关键能力:
- 精确控制代码块的数据库访问权限
- 在开发环境中模拟生产环境的数据库配置
- 验证读写分离策略的正确性
- 防止意外的写入操作流向只读副本
开发环境配置指南
第一步:修改数据库配置文件
打开项目中的config/database.yml
文件,在common
部分添加以下配置:
common: &common
adapter: postgresql
host: <%= ENV.fetch('CANVAS_DATABASE_HOST', 'postgres') %>
...
secondary:
replica: true
username: canvas_read_only
这段配置告诉系统:
- 存在一个名为
secondary
的数据库配置 - 该配置标记为副本数据库(
replica: true
) - 使用
canvas_read_only
用户进行连接
第二步:创建只读数据库用户
在本地开发环境中,我们需要创建一个专门的只读用户来模拟生产环境的权限设置:
docker-compose run --rm web psql -h postgres -U postgres -c "CREATE USER canvas_read_only WITH PASSWORD 'sekret'"
第三步:授予只读权限
为每个数据库(开发环境、测试环境等)授予只读权限:
docker-compose run --rm web psql -h postgres -U postgres -d <database name> -c 'GRANT SELECT ON ALL TABLES IN SCHEMA public TO canvas_read_only'
验证配置
配置完成后,我们可以通过Canvas的Rails控制台进行验证:
测试只读操作
GuardRail.activate(:secondary) { DeveloperKey.first }
这个操作应该能正常执行,因为它是一个读操作。
测试写入操作
GuardRail.activate(:secondary) { DeveloperKey.create! }
这个操作应该会抛出错误:
ActiveRecord::StatementInvalid (PG::InsufficientPrivilege: ERROR: permission denied for table developer_keys)
测试主数据库写入
GuardRail.activate(:primary) { DeveloperKey.create! }
这个操作应该能成功执行,因为主数据库有完整的读写权限。
最佳实践
- 开发阶段验证:在开发过程中尽早使用GuardRail测试读写分离逻辑
- 权限隔离:确保生产环境的只读用户权限与开发环境一致
- 错误处理:为可能出现的权限错误设计适当的处理逻辑
- 性能监控:在实现读写分离后,监控查询性能变化
常见问题
Q:为什么需要单独配置只读用户? A:在生产环境中,数据库副本通常是只读的。使用专门的只读用户可以在开发阶段就发现潜在的写入问题。
Q:GuardRail会影响所有数据库操作吗? A:不会,它只会影响在GuardRail.activate
块内执行的数据库操作。
Q:如何知道当前使用的是哪个数据库配置? A:可以通过检查ActiveRecord连接对象的配置来确定当前使用的数据库连接。
通过合理配置和使用GuardRail,开发者可以在Canvas LMS项目中实现安全可靠的数据库读写分离策略,为系统的高可用性和高性能打下坚实基础。
canvas-lms The open LMS by Instructure, Inc. 项目地址: https://gitcode.com/gh_mirrors/ca/canvas-lms
创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考