「3306π」北京站,2019年首发
2019新的一年,新的开始
3306π社区第一站北京站,拉开了帷幕
活动时间:2019年3月23日 09:00-18:30
活动地址:北京市朝阳区望京东园四区9号楼8层801阿里中心A座20层培训室(15号线望京东站C口)
本次技术交流特色:
- 专项培训和主题交流“双响炮”
- MySQL圈子的聚会,你学习知识,阿里出场地,3306π组局
本次会议安排如下
嘉宾
适合人群: MySQL DBA, 开发人员
培训前准备:
- 携带笔记本电脑
- 提前加入群领取资料准备环境
培训人数:限30人
主题1 《基于Raft的MySQL高可用组件Xenon实战》 吴炳锡
- Xenon的介绍及特点
- 业界高可用实现区别对比
- Xenon的raft实现
- Xenon部署及使用
- 对Xenon使用上的一些想法
从实战角度对比高可用:上一代的MHA,新一代的Replication-manager, orchestrator的实现,再看Xenon的功能实现及使用。
环境搞定后,大家肯定也会有一些自已的想法,那么下面的主题
主题2 《使用Go开发定制MySQL高可用组件Xenon》张雁飞
- Xenon项目结构
- Xenon中重要数据结构介绍
- Xenon高可用选举实现
- Xenon的切换流程实现
- Xenon在故障排查方面的实现
对想进一步了解MySQL高可用以及想定制化开发MySQL高可用的同学会有一定帮助哦。 这个主题针对Golang使用的同学全面剖析Xenon的实现及功能定制。
张雁飞也是开源软件:Xenon的主要作者
Xenon项目地址: https://github.com/radondb/xenon
(The MySQL Cluster Autopilot Management with GTID and Raft)
下午精彩内容
嘉宾及议题
主题1 阿里云 RDS MySQL 8.0
嘉宾 赵建伟(冷香)
阿里云 高级数据库专家
阿里云 MySQL 内核研发高级专家,曾任支付宝 Oracle DBA 专家,现阿里云 RDS MySQL 内核研发负责人
内容简介
阿里云 RDS 即将推出 MySQL 8.0 版本,除了官方 MySQL 8.0 推出的重大功能以外,我们在系统管理,性能优化, 新功能,稳定性方面做了很多加固,这次分享主要介绍这些功能优化的背景和技术。
主题2 MGR架构实践与故障分析
嘉宾 洪斌
爱可生技术服务总监
MySQL技术专家,现任爱可生技术服务总监,负责MySQL数据库在传统行业客户的应用推广与技术咨询,曾为运营商、银行、证券、保险、航空等行业内数家大型企业提供MySQL技术咨询服务。
内容简介
分享MySQL高可用方案MGR的多机房架构实践,MGR使用中的一些注意事项与常见问题,如何进行监控,节点故障如何自愈,从故障案例分析了解MGR的paxos机制。
主题3 MySQL趣味杂谈
嘉宾 张充
马蜂窝DBA主管
马蜂窝DBA负责人,从事数据库相关工作11年,同时也是知数堂的学员之一。主要负责MySQL、SQL Server相关运维、架构、自动化平台建设。
内容简介
MySQL和SQL Server高可用方案在实现机制的不同,希望将好的思路得以推广。
马蜂窝在MySQL高可用方案(PXC MGR)实施过程踩得的一些“坑”进行分享。
分享马蜂窝的中间件-DB Man设计架构。
马蜂窝“接地气”的相关数据库工具架构方案。
主题4 ClickHouse如何玩转时序数据
嘉宾 张健
QingCloud数据库研发工程师
目前就职与QingCloud数据库团队; 开源OLAP分析数据库ClickHouse的持续贡献者
内容简介
- 深入解读QingCloud如何基于ClickHouse构建时序数据库
- 为什么会选择ClickHouse。
- 如何利用ClickHouse进行时序场景分析 。
- ClickHouse原理揭秘。
- 未来展望。
主题5 MySQL新锐引擎MyRocks应用
嘉宾 莫晓东
前微信DBA
多年数据库架构经验,开源数据库资深DBA,曾负责过亿级支付数据库架构
内容简介
新锐引擎rocksdb在MySQL下的使用介绍,以及腾讯、头条等企业的使用情况。
「3306π」技术Meetup-北京站
主办「3306π」社区主办
赞助 爱可生、青云、知数堂
社区合作伙伴 阿里云栖社区、Mongoing中文社区、PostgreSQL中文社区、开源中国、IT大咖说、阿里云智能数据库产品团特队
时间 2019年03月23日 09:00-18:30
地点 北京市朝阳区望京东园四区9号楼8层801阿里中心A座20层培训室
报名链接:
低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。
持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。
转载内容版权归作者及来源网站所有,本站原创内容转载请注明来源。
- 上一篇
【阿里内部应用】基于Blink构建亲听项目以及全链路debug项目实时响应能力
案例与解决方案汇总页:阿里云实时计算产品案例&解决方案汇总 本文全面总结了大数据项目组在亲听项目以及全链路debug项目上进行的实时流处理需求梳理,架构选型,以及达成效果 一、背景介绍 1.1亲听项目 亲听项目专注于帮助用户收集、展示、监控和处理用户体验问题,是保证产品的主观评价质量的利器,关于其具体功能可参考在ata搜索"亲听"查看系列文章。目前亲听项目的实时流处理需求来自算法效果监控,算法效果监控需要对上游TimeTunnel日志进行解析后经过处理得到一些关键指标,亲听通过对这些指标的前端展示和阈值监控报警达到算法效果监控目的。 需求要点可以总结如下: 上游需要处理的TimeTunnel日志的实时数据量大约在日常峰值每秒数万条记录,大促峰值每秒几十万条记录 从用户搜索行为到亲听系统得到搜索行为指标数据秒级的低延时 数据的处理逻辑较为复
- 下一篇
ARMS 3月有奖评测活动开始啦!分享你的专属使用体验,赢Beats耳机等多重好礼!
不要慌,上面只是一张贴图。 为什么“慢”那么难查 **网站卡顿、页面加载过慢是互联网应用最常见的问题之一。排查、解决这类问题通常会花费开发运维人员大量的时间,通常是因为以下三个原因: 应用链路太长,无从下手。 从前端页面到后台网关,从Web应用服务器到后台数据库,任何一个环节的问题都有可能导致请求整体卡顿,到底是前端资源加载过慢?还是数据库出了问题?还是新发布的服务端代码有性能问题?出现问题的原因五花八门。 采用“微服务”架构的应用,链路更加复杂。不同组件可能由不同的团队、人员分别维护,加剧了问题排查的难度。 日志不全或质量欠佳,现场缺失。 应用日志无疑是排查线上问题的神器,但出现问题的位置往往无法预期,发生了问题通常会发现日志信息不全 -- 我们不可能在每一个有可能出现问题的地方打印日志。 “慢”的定义偏主观,“慢”有时候往往也是偶发现象。真正
相关文章
文章评论
共有0条评论来说两句吧...
文章二维码
点击排行
推荐阅读
最新文章
- Jdk安装(Linux,MacOS,Windows),包含三大操作系统的最全安装
- SpringBoot2更换Tomcat为Jetty,小型站点的福音
- CentOS8安装Docker,最新的服务器搭配容器使用
- SpringBoot2整合MyBatis,连接MySql数据库做增删改查操作
- CentOS8,CentOS7,CentOS6编译安装Redis5.0.7
- 设置Eclipse缩进为4个空格,增强代码规范
- Docker使用Oracle官方镜像安装(12C,18C,19C)
- CentOS8编译安装MySQL8.0.19
- SpringBoot2整合Redis,开启缓存,提高访问速度
- SpringBoot2配置默认Tomcat设置,开启更多高级功能