彭立勋_MySQL在云端-挑战、需求、Bug.pdf

MySQL在云端 —— 挑战、需求、Bug TOPIC •  云端MySQL的挑战 •  云端MySQL的需求 •  云端MySQL的Bug 云端MySQL的场景 •  用户行为不可控 •  用户水平不可控 •  用户高峰不可控 •  用户应用不可控 •  中间件要对数据库进行管理 •  中间件的引入要对用户透明 •  如何破解？ •  ——定制化MySQL版本，假设用户都是小白 云端MySQL的需求 •  系统账号占用用户资源——多用户组 •  用户表不建主键——隐式主键 •  用户不知道内存占用情况——线程内存监控 •  用户不小心误操作数据——数据闪回 •  连接IP显示为中间件IP——透传用户连接IP 多用户组（1） •  云数据库的权限体系 •  客户账号：供给客户使用的账号，只能操作用户自己的表结 构和数据，不能干预上层调度系统的账号和复制账号的行为 •  管理账号：供给上层调度管理系统使用的账号，用于数据库 状态监控，为客户创建账户，不能干扰客户账号的连接 •  系统账号：用于复制、备份的账户，不能被其他账户干扰 •  MySQL支持的权限体系 •  SUPER用户：可以修改GLOBAL的参数，不受最大连接数限制 •  非SUPER用户：不可以修改GLOBAL的参数，受最大连接数限制 •  显然，只区分SUPER和非SUPER的权限体系不足以支撑云数据库的 场景 多用户组（2） •  我们的改进 •  Root用户组：只有一个ROOT用户，用于初始化和救急 •  Maintain用户组：管理用户组，采用单独的连接数总和限制， 不计入max_connection，自动拥有SUPER权限 •  Sysinfo用户组：系统用户组，采用单独的连接数总和限制， 不计入max_connection •  Normal用户组：普通用户组，采用max_connection限制 •  未来改进方向 •  可以动态添加新的用户组 •  可以为每个用户组设置最大连接数限制 •  可以为每个用户组设置默认权限集 隐含主键（1） •  主键对复制的重要性： •  为了用户数据安全，binlog_format最好设置为ROW •  但是如果ROW格式的Binlog Event在备库Apply时一律采用主键 进行匹配 •  如果表上没有发现主键，自动蜕化为全表扫（版本5.6） 隐含主键（2） •  我们的改进 •  如果遇到无主键表，先看二级索引中是否有唯一键，如果有则 采用唯一键进行匹配 •  如果没有唯一键则看有没有普通索引，有则用第一个最长的索 引进行检索 隐含主键（3） •  最极端的情况：用户的表上没有任何索引？怎么整？ •  用户在CREATE TABLE时如果没有任何唯一键且没有定义自增字 段，则自动创建一个自增主键 •  用户在ALTER TABLE时如果要把表修改到无任何唯一键且没有 自增字段的结构，则自动在目标表结构上添加一个自增主键 •  在所有DML操作中隐藏隐含主键的存在 •  在所有逻辑读取操作中隐藏隐含主键（包括逻辑checksum） 隐含主键（4） •  当用户自己意识到了主键很重要时 •  如果用户ALTER TABLE的目标结构中存在任何唯