Tag Archives: MySQL

使用 mmm-manager 管理云环境中的 MySQL 双主实例

By | 2019-01-28

介绍说明 在之前的工具中, mha_switch 和 mha_manager_consul 的使用都是建立在虚 ip 漂移的基础上实现的高可用方案. 不过在云环境中, 目前很多的云厂商还不支持虚 ip 漂移的功能, SLB(负载均衡)等没有类似 haproxy 的 backup 模式, 所以不适用于单 master 读写的场景. 如果使用 SLB 代理多 master, 则很难保证数据一致性问题(比如主从延迟). 一些组织在使用云环境的时候可能首要考虑数据安全性, 这种情况下可能不会考虑 RDS 之类的服务, 而是在云主机中自建 MySQL 实例, 并且最好占用整个宿主机. 如果自建实例, 就一定需要考虑高可用方案, 在不支持虚 ip 漂移的情况下, dns 服务或者绑 hosts 文件是个可选的方案, 在故障切换的时候做好对应的记录修改即可, 不过这种方式需要业务做对应调整, 在业务复杂的场景下, 需要保证修改记录的准确性和及时性. mmm-manager 则提供了另一种方案用来管理双主满足高可用的需求. 不过该方案依赖一些编程语言驱动的特性支持. 对于不支持特性的编程语言, mmm-manager 提供了更新 redis key 值,… Read More »

使用 Percona Server auto manager 管理数据库

By | 2018-04-02

介绍 Percona Server auto manager 是基于 percona-server-5.6.39.83.1 的一个分支版本, 其增加了 memcached 记录和 sql 过滤的功能, 用来降低管理员操作数据库的风险. 不同于 inception 的深度修改, Percona Server auto manager 仅修改客户端的 client/mysql.cc 和 client/mysqldump.c, 不影响 server 端的功能. 说明: memcached 功能用来记录用户输入的用户名及密码, 这点在一次一密登录 mysql 的时候比较有用, 由于 mysql 命令行是将最终的密码哈希结果传给 server, 所以中间件等软件无法得知用户输入的验证信息, 如果一次一密是有状态的则可以通过时间等方式算出验证信息 比如 google totp, 如果是无状态的则中间件代理等工具无法得知验证信息. 当然我们也可以在 client 代码层完成验证, 不过这种方式存在局限性, 不够通用; sql 过滤功能则主要用来限制开发者或管理员对数据库表的修改, 可以使用 –skip-sql-filter 选项忽略此功能, 具体的限制规则见下文.… Read More »

mha_switch: 结合 proxysql 和 MHA 切换 MySQL 主从

By | 2017-11-18

mha_switch: 结合 proxysql 和 MHA 切换 MySQL 主从 在之前的文章proxysql 介绍及测试使用中, 详细介绍了 proxysql 的安装配置等, 不过经过时间的推移, proxysql 工具做了很多的改进, 自动检测及状态切换等功能带给我们很大的便利, 可以取代传统的 haproxy 代理, 不过由于 proxysql 的检测和状态切换机制不是实时进行, 只是间接性检测, 所以会带来了另外的困扰, 如何与已有的工具如MHA更好的结合以保证数据的一致性. 功能介绍 mha_switch 通过在自定义的脚本中加入 proxysql 检测和切换的功能比较方便的实现了 MHA 和 proxysql 之间的配合使用. mha_switch 主要实现以下功能: 解析 masterha-script.cnf 的实例配置信息; 切换 vip 信息(可选, 如果实例通过 vip 对外服务); block/release 数据库用户; prxoysql 切换; 配置说明 自定义脚本读取 masterha-script.cnf 文件获取主从实例和 proxysql… Read More »

动态代理 MySQL slave 端口

By | 2017-10-16

背景介绍 一直以来我们的数据库主从架构都以 vip 作为高可用的基石, 通过 vip + MHA 的方式完成 master 的高可用, 并未对 slave 进行相关的高可用设计. 随着时间的推移, 为了减少一些业务对 master 的繁重的操作, 线上的一小部分业务开始连接 slave 对外提供服务. 这些常见的业务包括以下类型: 1. op 相关的工程, 统计类大查询; 2. 日志分析类的查询操作; 3. 使用 atlas 进行读写的业务; 4. 主从延迟无关, 以读为主的业务; 我们现有的业务中, 并未使用 atlas, proxysql 等中间件, 所以 op 后台类的业务查询都通过 slave 服务. 不过在过往的几次故障案例中, MHA 切换主从后会出现以下情况: +——–+ +——–+ | vip | | vip… Read More »

如何实现 MySQL 的一次一密登录

By | 2017-08-18

如何实现 MySQL 的一次一密登录 背景介绍 在日常工作环境中, 开发或者测试人员经常需要连接测试库、线上库等查看表结构或数据来验证程序的功能. 实际上让 DBA 协助开发者查看信息会是特别繁琐且无趣的事情, 所以为了方便起见会将数据库的权限分发给开发或者测试人员. 不过长此以往下去有几件事情会让我们烦恼不已: 1. 账号会在开发者之间相互传递; 2. 为了方便开发者会以快捷命令的方式查看信息, 密码信息容易暴露; 3. 开发者忘记密码, DBA 可能需要重置以通知所有其他人员修改密码; 事实上, 上述几种情况是很难避免的, 只要有人工参与就会有这些潜在危险的隐患, 所以我们就需要提供一个相对方便记住的又能保证相对安全的方式供开发者使用. 下面则从不同层面简单的对这种方式进行描述. 管理主机 如果从系统层面来看, 我们建议最好把所有的开发者都集中到一台管理主机上登录, 只有开发者连接到这台机器上, 才能通过该机器连接测试库, 线上库等进行查询信息操作. 如下图所示: +————+ ssh +————–+ +———–+ | developers | ———-> | manager host | ———> | databases | +————+ +————–+ +———–+ 开发者通过 ssh 登录该主机, 这个步骤最好是以… Read More »

使用 dbweb 修改数据库表结构

By | 2017-07-14

1. 说明 我们以 dbweb 工程为基础, 增加了一些功能上的限制, 来方便开发人员直接修改线上的数据库表结构, 修改及增加的更新包括: 1. 去掉原有的修改密码功能; 2. 增加 google totp 密码验证, 每登录一次需要获取最新的密码信息; 3. 限制 sql 执行, 包括以下限制: `delete/update` 语句必须带有 where 条件; `select` 语句必须带有 where 或 limit 条件; 禁止执行以下 sql: use <database> create <database/schema> alter … drop drop <database/schema> drop/truncate <table> purge … grant/revoke .. 格式化 sql; 4. 超过 200MB 大小的表禁止 alter… Read More »

基于 consul 架构的 MHA 自动切换

By | 2017-06-08

介绍 一直以来, 我们并未在线上启用 masterha_manager 自动切换脚本, 主要因为在网络抖动(网线, 所属机柜交换机不稳定)的情况下并不能保证数据库真的不能访问. 比如重启检测脚本所在机器的网卡并不能说明数据库出了问题, 所以从这方面看我们不能仅通过一个点的检测就判断数据库不可访问. 不过我们可以通过 consul(因为 consul 提供 dns 接口, 笔者更倾向于使用 consul, 而不是 etcd)集群的特性, 我们增加多点检测机制, 在 n 个集群的环境中, 有超过半数的检测点检测到数据库有问题, 我们就认为数据库不可访问, 这时则开始调用 masterha_manager 脚本进行切换, 如下图所示: <checkmysql> <checkmysql> <checkmysql> | | | +———+ +———+ +———+ | consul1 | | consul2 | | consul3 | +———+ +———+ +———+ \ | / \ |… Read More »