Tag Archives: MySQL

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 »