百度实习经历报告以及 onlineschemachange 项目和 ddbs 的简介 [email protected]...
Post on 19-Dec-2015
460 views
TRANSCRIPT
百度大厦生活照
大纲
• OnlineSchemaChange 项目OSC的背景和需求OSC的实现OSC可能的问题和改进建议
• 百度 ddbs 系统ddbs的系统架构和功能模块的介绍ddbs中的基本策略
大纲
• OnlineSchemaChange 项目OSC的背景和需求OSC的实现OSC可能的问题和改进建议
• 百度 ddbs 系统ddbs的系统架构和功能模块的介绍ddbs中的基本策略
OnlineSchemaChange 项目 ---- 背景和需求• 未作修改的 Mysql 做 Schema Change 时候的流程:
– 对源表加读锁或者写锁以阻塞新的访问请求– 按照新的 schema建立临时目标表– 将源表的数据拷贝到临时目标表– 将源表改名为临时表,将临时目标表改名为源表 – 删除临时表(源表)– 释放读锁或者写锁问题:整个拷表的过程是锁表的;线上业务不可接受!
• 需求:– 对于使用 Innodb 引擎的表,进行 schema change 的时候,从功能上看不会影响
对该表的读、写访问。– MySQL 参数中可以配置 Schema change 批量拷贝的速度,用来控制 Online
Schema Change 的 I/O 对线上应用的冲击。– 对一个表,可以将多个 schema的修改请求合在一个 Alter SQL语句中。 当一个
schema change正在进行时,对同一个表的后继 schema change请求将被阻塞。在当前 schema change完成后,后继的 schema change请求才会被执行。
– 对不同表的 schema change操作可以并发进行。
大纲
• OnlineSchemaChange 项目OSC的背景和需求OSC的实现OSC可能的问题和改进建议
• 百度 ddbs 系统ddbs的系统架构和功能模块的介绍ddbs中的基本策略
OnlineSchemaChange 项目 ---- OSC 的实现1• 初始数据结构和运行环境的初始化
需要锁表,但是时间很短的
• 源表的拷贝(非常耗时的部分)– 为了不影响线上业务的 IO拷贝一定数量的记录后会睡眠;– 在这个过程中对源表的查询访问可正常进行。– 在这个过程中,对源表的插入、删除、更改操作也会正常进行,但会被额外的记录在 OSC日志中,并且定期刷入磁盘。
• 在线日志重演– 为了不影响线上业务的 IO拷贝一定数量的记录(一个 block)后会睡眠;– 在这个过程中对源表的查询访问可正常进行,对源表的插入、删除、更改操作也会正常进行,但会被额外的记录在 OSC日志中,并且定期刷入磁盘。【同上】
• 离线日志重演– 需要锁表;– 先处理日志文件中可能存在的记录,再处理内存中的记录。
OnlineSchemaChange 项目 ---- OSC 的实现2• 前期的判断:
– 只有需要进行表的拷贝的时候才会触发 OSC(像 rename table这样的才做就不会触发 OSC)
– 判断是否属于 OSC的支持类型: 1、对于表的修改,只能处理增加 (删除 )一列或若干列。 2、对于所增加的列,必须可为空。 3、对于索引的增删改没有限制。当 schema的变化超出了 Online Schema Change当前设计所能处理的范围,则退出,继续MySQL默认的 schema change流程。
• 日志机制:– 内存数组 +日志文件:内存数组满了之后会刷到磁盘;每次刷到文件的记录,组成一个 block,有 osc_env->header指定记录条数和大小。
– 日志重演与操作的添加有互斥锁同步,日志重演的位置会被记录在 osc_env->log_file_offset中,它指向下次日志重演的文件偏移。
大纲
• OnlineSchemaChange 项目OSC的背景和需求OSC的实现OSC可能的问题和改进建议
• 百度 ddbs 系统ddbs的系统架构和功能模块的介绍ddbs中的基本策略
OnlineSchemaChange---- 可能的问题和建议
• Mysqld 停掉, log_in_memory[OSC_LOG_CAPACITY] 会立即被刷到磁盘吗?【 schema-change 没有做完, innodb 会自动回滚重做】。
• 两次更改的问题,在旧表中的操作被记录在日志中以后,又会在新表中重演;
• 暂停拷表的时间间隔 osc_io_interval 是否可考虑随着线上服务请求的繁忙程度而动态改变;
• 内存日志记录容量 OSC_LOG_CAPACITY 是否也可以动态;以便适应复杂的环境;
大纲
• OnlineSchemaChange 项目OSC的背景和需求OSC的实现OSC可能的问题和改进建议
• 百度 ddbs 系统ddbs的系统架构和功能模块的介绍ddbs中的基本策略
ddbs 系统框架 ---- 整体架构
2 zookeeper
tablet_server_cluster
tablet_server
ts_agent
tablet_server_cluster
1 tablet_server
4 ts_agent
5 dbproxy
3 cli
客户端 客户端
管理员
目前在使用的百度产品线
• 百度百科• 音乐电台——百度听• Linkcache——百度新闻的缓存• Logdata——某产品的日志文件• 等等
ddbs 系统框架 ---- 系统接口
• 支持的命令– 有限制 select/insert/update/delete/replace/
• 如果只涉及到单机表,且在同一个 ts上,无论多复杂都可以支持。• 分布式表,不支持嵌套子查询。• 如果是单表单机或者多表单机,支持 order by / group by / limit/ 单机事务。• 如果是单表多机的情况,支持 order by / group by,支持不带 offset的 limit,不支持分布式事务。
– 事务命令 start transaction/beigin/commit/rollback,不支持分布式事务– set命令– use命令
• 不支持的命令– prepare,正在开发中…– 调用存储过程、 show、 kill
– CREATE 类、 ALTER类的 DDL命令
ddbs 系统框架 ---- 数据划分
• 数据划分:在 DDBS中,将一张分布式表按照指定的 Partition Key和 Partition Mode分成多个数据片(称为 Tablet),分散在多个数据存储节点中,一般情况下,一个 cluster里面只有一个 Tablet。
• Partition Key:是 DDBS 中用于数据划分和定位的属性,该属性是应用创建的分布式表中的一个字段。 Partition Key 的选择决定了数据按照哪个字段来进行数据分布和组织,一张分布式表只能有一个 Partition Key。 Partition Key 与 Tablet的索引并无强制对应关系。
• Partition Mode:是 DDBS 中用于数据划分的方式,常用的数据划分方式包括基于 Partition Key 的按范围划分、按散列取模划分、按时间划分、按枚举 /列表划分、以及前几种划分方式的组合(称为组合划分)等。
ddbs 系统框架 ---- 数据划分(例子)
• CREATE DISTRIBUTED TABLE IF NOT EXISTS disIntRange1
• (
• intID INT NOT NULL PRIMARY KEY,
• name VARCHAR(1000)
• )ENGINE = InnoDB
• PARTITION KEY (intID INT)
• PARTITION BY RANGE
• {
• ([MIN, 1000], 'tablet__fengchao__disIntRange1__0' TO 'tablet_server_cluster__fengchao__1'),
• ([1001, 10000], 'tablet__fengchao__disIntRange1__1' TO 'tablet_server_cluster__fengchao__2'),
• ([10001, MAX], 'tablet__fengchao__disIntRange1__2' TO 'tablet_server_cluster__fengchao__3')
• };
ddbs 各模块功能介绍 (zookeeper)
• zookeeper:主要用于存储元数据,包括表信息、划分信息、权限信息等等。– /ddbs/sys_user tsagent的帐户相关信息;– /ddbs/machine 集群机器;– /ddbs/command_status/cli cli登录信息;– /ddbs/product/产品名 / tablet_server mysql信息;– /ddbs/product/产品名 / tablet_server_cluster mysql_cluster信息;
– /ddbs/product/产品名 / tablet_server_agent 管理代理信息;– /ddbs/product/产品名 / table 表信息;– /ddbs/product/产品名 / tablet 表的分片信息;– /ddbs/product/产品名 / dbproxy dbproxy的配置信息;– /ddbs/product/产品名 / product_user 应用用户帐户信息;
ddbs 各模块功能介绍 (cli 常用命令 )
table: create/register single/distributed; truncate; remove; alter distributed ;
tablet_server: show; add; set; remove;
tablet_server_agent: show; add; set; remove;
sys_user: show; add; set; remove;
machine: show; add; set; remove;
tablet_server_cluster: show; add; set; remove;
product_user: show; add; set; remove;
dbproxy: show available_dbproxy/dbporxy_conf/dbproxy; set dbproxy_conf;
其它: install ddbs; install product; show product list;
ddbs 各模块功能介绍 (dbproxy)
服务框架
处理请求
配置文件更新,及重启服务
客户端网络:连接,认证,读,写
后端网络: conn_pool管理数据库连接,负载均衡
用户权限认证,连接数管理
日志分析和定期上传
sql协议的实现,mysql internal protocol
sql语句解析:解析 sql的类型,各部分
sql语句分解:分解原 sql到为多个 sql语句
sql路由:将分解后的 sql转发到相应的 ts,包括读写分离;
穿透指定数据库服务器功能
缓存命令处理
结果合并:按不同策略合并结果
ddbs 各模块功能介绍 (tsagent)
DBA 控制命令传递 cli 传递过来 SQL 命令给 ts:包括 DDL命令、 SHOW命令。
监控 Tablet Server 的运行情况监控 Tablet Server是否存活, 监控主从同步是否正常, 监控 Table Server的数据量, 监控 Table Server的负载,主从切换等。
监控 Tablet Server 所在机器的运行情况检查本机的资源状况,例如:内存情况,网卡流量情况,磁盘空间情况、磁盘 I/O情况、 CPU 情况,并计算本机的负载估计值。
大纲
• OnlineSchemaChange 项目OSC的背景和需求OSC的实现OSC可能的问题和改进建议
• 百度 ddbs 系统ddbs的系统架构和功能模块的介绍ddbs中的基本策略
重要策略 ---- 主从分离query->args
当前是否在事务中
MS_SLAVE MS_MSTER
是
上次 query在事务中
写操作
是
是
读,但时间未到;是
读操作是
重要策略 ----load balance
• 如果当前连接池中有干净的连接实例,那就从中取出。如果没有,或者连接失败了,需要重新建立一个新的连接。
• 如果一条命令落在主库上,因为只有一个节点,所以不需要负载均衡处理;
• 如果一条读命令落在从库上,有多个从库可选,那么从中选出 当前连接数 /权值(权值是配置的) 最小的一个slave。
重要策略 ----tsagent 的单点切换
• 当检测到master不存在时,开始单点切换(由 leader来控制,当前 cluster中 nodes中 id最小的为 leader)
• 查找 tinker,并与 tinker进行出具补齐;• 在 slave节点中查找并选举master
leader节点向集合 R集合查询各个节点的权值,找到权值最大的节点,记为master。
• 通知 R+S新master, R+S各结点都 change master到新master
• 完成单点切换并清理Leader通知master完成切换Mater如果存在 parent则尝试加入master写 running_info/master
master删 running_info/status
Leader回到 S4状态
重要策略 ---- 结果合并
• 检查结果是否都执行成功;• 如果是单机命令,返回单机结果;否则,• 对 insert, update, replace, delete操作,执行merge_without_result_set,超过 500个分片时候,有问题;
• 对 select操作执行merge_with_result_set,具体如下:
max/min/sum/c
group by
order by
处理方法
0 0 0 直接合并输出;
0 0 1 归并排序输出;
0 1 0 归并,同 key只输出一个;
0 1 1 发送命令去掉 order by;结果归并,同 key只输出一个;排序;
1 0 0 合并结果,只输出一行结果;
1 0 1 合并结果,只输出一行结果;
1 1 0 归并,再做 max/min/sum/count处理;
1 1 1 发送时去掉 order by,对结果做归并,最后做全结果排序;
百度实习的收获
• 1、工程经验——段错误的处理, core文件;
• 2、做事的专业程度——执行力;• 3、与同事的沟通;
Q&A
谢谢!