my sql管理基础 李春_v2
DESCRIPTION
mysql overviewmysql replicationmysql HATRANSCRIPT
MySQL DBA Team
李春 http://www.hatemysql.com
MySQL 管理基础
B2B DBA 全家福
内容概要
• MySQL Overview
• MySQL Replication
• MySQL HA
MySQL 结构层次
• MySQL 提供一个抽象层，允许不同的存储引擎使用相同的API 对表进行访问
• 该接口通过一个被称为 Handler 的抽象类来实现
• 该处理器提供了一些可实现基本操作的方法，如： 打开和关闭表、连续扫描记录、按键值检索记录、存储记
录以及删除记录 等
• 每个存储引擎都执行处理器的一个子类以实现接口方法，以便将处理器操作转化为特定存储引擎的此层次存储 / 检索 API 调用
存储引擎机制
MySQL 主要存储引擎
• NDB ( 集群引擎 )
• Archive ( 归档引擎 )
• Memory ( 内存引擎 )
• MyISAM ( 非事务引擎 )
• InnoDB ( 事务引擎 )
性能不符合要求
仅支持 SELECT 、 INSERT 操作
数据保存在内存中
√
√
• MyISAM ：表级锁，不支持事务
• Innodb ：行级锁，支持事务， 高并发
• 默认采用 Innodb ，处理高并发情况下的数据访问
• MyISAM 用于历史表，基本上没有更新的，不涉及业务
MySQL 存储引擎选择
InnoDB 索引结构
InnoDB vs MyISAM on Index
InnoDB 物理文件组成
InnoDB 物理文件组成• InnoDB 的数据文件包括：
innodb_file_per_table
• .frm 表结构文件• .ibd 表数据文件（数据目录）• 系统元数据和 undo space （共享表空间）• ib_logfile* 重做日志文件 （ Oracle 的 Redo Lo
g ）
• INSERT BUFFER
Innodb 使用 insert buffer 作为缓存：它并不马上更新索引的叶子页，而是把若干对同一页面的更新缓存起来，一次性更新，从而有效节约 I/O
InnoDB 优化设计
• DOUBLE WRITE
InnoDB 在将数据写到数据文件的时候，会出现只写了一半但由于某种原因剩下的数据没有写到 innodb file 上如果 double write buffer 写成功的话，但是写磁盘失败，innodb 就不用通过事务日志来计算了，而是直接用 buffer 的数据再写一遍
InnoDB 优化设计
• ADAPTIVE HASH INDEX
InnoDB 存储引擎会监控对表上索引的查找，如果观察到建立哈希索引可以带来速度的提升，则建立哈希索引，所以称之为自适应（ adaptive ）哈希索引
InnoDB 优化设计
Adaptive Hash Index
内容概要
• MySQL Overview
• MySQL Replication
• MySQL HA
• 提供实时热备，保证高可用性
• MySQL 的所有高可用架构都是基于复制的， Replication 是高可用的核心和基础
DBA 的使命：提供高可用，可扩展，高性能的数据存储服务
Replication 作用
• 将在 A 机器上执行的所有 SQL 序列在 B 上原样重复执行一遍
• 在 MySQL 中称之为 ： statementbinlog-format=statement
• mysqlbinlog 工具mysqlbinlog binlog 文件名
实现方式 1
• rand() 函数• uuid() 函数• 自增......
statement 方式的问题
• 将在 A 机器上数据行的变化在 B 上原样做一遍
• 在 MySQL 中称之为 ： row
binlog-format=row
• mysqlbinlog 工具
mysqlbinlog binlog 文件名
实现方式 2
• mysqlbinlog -vv
mysqlbinlog
• binlog 文件大小的问题
如： update a set c1=100 where id <1000000;
row 方式的问题
• Statement 和 row 方式的组合
• 在 MySQL 中称之为 ： mixed
binlog-format=mixed
• mysqlbinlog 工具
mysqlbinlog binlog 文件名
实现方式 3
• 第二种方式： binlog-format=row
• 理由：
statement 可能造成主备不一致
一次更新很多行的情况在网站的数据库上应用很少erosa解析日志需要 row 方式
线上数据库选择
MySQL 复制基本原理
• MySQL Replication 的基本原理是通过 binlog 复制应用的方式来还原数据
• MySQL 通过 server_id 来识别产生 binlog 的主机，因此即使双Master 复制，也不会出现 binlog 被重复应用
MySQL 复制基本原理
• 复制线程分为 Slave IO 和 Slave SQL ： Slave IO线程只负责注册到 Master 上，读取 binlog ，然后解析到本地， Slave SQL线程只负责把 Slave IO线程产生的可执行 SQL 应用到本地
• 避免主键冲突， MySQL 提供了auto_increment_increment 和 auto_increment_offset 来控制主键生成的序列，只要双Master 的两台主机没有相同的序列，就绝对不可能复制冲突
MySQL 复制基本原理
双向复制
级联复制
双向 + 级联复制
• 环形复制架构
• 1 Master + n slave 读写分离架构（百度）
其他复制架构
内容概要
• MySQL Overview
• MySQL Replication
• MySQL HA
• HA （ High Availability ）作用
提供高可用方案
• HA 的需求
提供透明的数据库访问，即使 MySQL 主机宕机
• 实现方式：
Heartbeat
Cobar
为什么需要 HA
Heartbeat 1
Heartbeat 2
• 优点
开源，发展迅速，目前为 3.0版本
双 master 结构， VIP漂移
• 缺点
脑裂问题
不支持分库
VIP漂移应用需要重连数据库
Heartbeat 优劣势分析
Cobar 1.0
• 优点 平台部门开发
支持分库 连接池管理
JDBC协议
• 缺点所有 SQL 都需要带上分库键的 where条件
cobar 内存限制 各 cobar 服务器之间没有通讯
Cobar 1.0 优劣势分析
Cobar 1.1
• 优点
连接池管理
MySQL协议
没有 cobar 内存限制
• 缺点
不支持分库
推出时间不长，未进入稳定期
Cobar 1.1 优劣势分析
Offer 集群架构解析
Virtual partition
Virtual partition
Virtual partition
Virtual partition
Virtual partition
Virtual partition
Physical node
Virtual partition
Virtual partition
Virtual partition
Virtual partition
Virtual partition
Virtual partition
Physical node
Virtual partition
Virtual partition
Virtual partition
Virtual partition
Virtual partition
Virtual partition
Physical node
Virtual partition
Virtual partition
Virtual partition
Virtual partition
Virtual partition
Virtual partition
Physical node
Virtual partition
Virtual partition
Virtual partition
Virtual partition
Virtual partition
Virtual partition
Virtual partition
Virtual partition
Physical node
Physical node
Virtual partition
Virtual partition
Virtual partition
Virtual partition
Virtual partition
Virtual partition
Virtual partition
Virtual partition
数据切分策略 --Virtual Partition Hash
推荐书目
Q&A