满载干货的北京站沙龙,你都错过了什么?(附PPT下载)

杨建荣 2017-03-13 11:06:21

 

 
 

Tips:登陆云盘:http://pan.baidu.com/s/1bQauxK 即可下载本次北京站沙龙PPT。

 
 

 

 

转眼间,2017已经爬上了眉梢,在有序计划中,DBAplus社群北京站沙龙拉开了序幕。

 

 
沙龙初衷之我见

沙龙活动不光是聚聚人气,我用三句通俗的话来解释。第一句是:技术越来越值钱,但是钱不值钱。这句话不一定对,但是能够说明一些道理,我们可以让技术在交流中更加深入,互相学习成长;第二句是:很多时候最大的问题是我们不知道问题在哪儿。不要想着埋头苦想能够解决一切事情,多听听多问问,其实花不了太多时间。第三句话是:社群中不需要顾问,我们需要真正做事情的人。因为兴趣和爱好走在一起,本来已经不容易,我们需要实实在在做点事情的人。

 

 
从社群组织者的角度来看

我全程参与了从2015年至今所有北京站的沙龙活动,如果让我从组织者的角度来说说感受,我会从场地、会场布置、直播、报名工作几个角度来谈。目前为止,我感到整个沙龙工作越来越专业化,逐渐抛开了更多的个人色彩和力量,而是一个社群整体的形象和贡献。

这话怎么圆呢?因为场地是社群的策划在张罗,刚开始有两处可选,一处在青年路的大悦城附近,另一个处就是这次沙龙所在的场地(在望京南),最后看起来望京的这个场地氛围更活泼亮丽一些,没错,就是这里。

 


会场布置是由无界空间来负责的,而直播工作则是由IT大咖说来负责,我们一下子少了很多负担。要是以前,我得提前找好一个空闲手机,找一个朋友来全程录制,还要考虑话筒的电池量等琐碎的事情,光是开场前的布置和调试就得花去个把小时。沙龙的报名推送是社群统一来做,从入座率来看和预期基本一致,有几位朋友还给我打来电话发来短信告知无法到场,大家的认真对待让我感到很欣慰。

当然每到这个时候,我都会想起在前几次沙龙中那些默默支持和帮助我们的小伙伴们,是你们让我们曾经走过的荆棘之路充满了希望。

 

 
沙龙现场回放

 

首先就是会场的布置,有了合作伙伴和更多朋友的支持,我们只需要更多关注于沙龙的质量。在此重点感谢新炬网络谢云辉和杨光的帮助。

我们先做了简单的调试,没过一会,大家都争相赶到了。看着空位子越来越少,我悬着的心终于放了下来。这是在沙龙进行中拍的一张。

 


首先由我做了一个简单的开场——社群介绍。其它内容就不多提了,我给出一个数据即可。这些主要是我们在2016年做出的一些成绩,数据绝对经得起推敲。

 


紧接着,三位讲师带着大家开始了技术之旅。

 

1
数据库审核平台实践

 

第一位上场的是韩锋老师,他分享的是宜信数据库审核平台的实践经验。他表示,数据库设计质量、SQL运行效率,对数据库稳定运行非常重要。数据库审核平台可以快速发现和定位问题,大幅提升DBA工作效率,研发人员也可对自己研发系统的运行情况做到心中有数。随着DBA传统运维职能不断弱化,在数据库结构设计、SQL优化方面会逐步成为工作重点。审核平台,正是着眼于此,是性能优化之利器。希望大家能逐步重视这方面的工作,也希望能支持此类开源平台。

 


听了韩老师的分享,我脑海里闪现了一个想法,那就是“复杂的事情简单做,简单的事情重复做,重复的事情用心做”,我觉得韩老师他们做到了。

 

2
Oracle XTTS迁移

 

第二个主题是由新炬网络杨光老师带来的关于XTTS的迁移分享,对于传统的Oracle数据库迁移方式来说,数据量越大,往往需要的停机时间越长。增强版的XTTS支持了跨平台增量备份,使用增量备份的方式,可以将前期的数据文件传输、数据文件转换等操作在不中断业务的情况下操作。然后通过多次增量备份恢复,使源端和目标端的数据差异降到最小,保证最终业务停机时间只需要申请较短的时间。

 


提问环节时,我做了简单的补充:XTTS不是最好的方案,但确实是一个不错的迁移方案,比如Windows平台和Linux平台的迁移,如果在11g可能异构的Data Guard就是一种很不错的方法;如果是10g数据库迁移到新的服务器,同时升级数据库为11g,那么Data Guard切换后,导入系统表空间数据也是一种不错的方法,在12c这个还有提升;如果是大量blob数据的情况,OGG就不是一个很好的方案,这个时候就是XTTS。所以没有最好的方案,只有最合适的方案。

 

3
MySQL Docker化实践

 

去IOE这几年在互联网公司落实得比较领先,MySQL在其中是一个主力军。京东的Docker集群数量惊人,达到了近15万规模,应该是目前最大规模的,这其中也是不断从非核心系统逐步演进过来的,对此,京东的资深数据库专家刘风才老师做了非常精彩的分享。里面有很多细节需要注意,而且这是一个行业前瞻的实践,必然会踩到不少坑,里面甚至会有专门的团队来定制Linux内核。要想做大做好,真不是一件简单的事情。在经历了618、双11大考之后,这种方案显得更有技术说服力。

 


对此我的一个观点,也可以算是一个忠告吧:对于部分小公司来说,只有几台服务器的情况下,Docker可能不是一个好的主意,弄不好还会出篓子,不如直接上几个云服务器,RDS更加实惠,出了问题至少不用DBA直接背锅;而对于大型企业和海量应用,这就是一个必然的选择。从很多细节来看,他们不仅仅是用,而且还需要做到技术可控的定制。这种经验不可复制,但是弥足珍贵。我们可以一窥优秀企业的实践经验,让自己开开眼界。

刘老师的分享引起了全场的极大兴趣,我保守估计,他至少回答了15个问题。这在很多技术大会中是无法做到的。

 

4
深度交流的内部讨论会

 

演讲结束之后,很多同学还意犹未尽,看时间还在计划之中,我们提议部分同学参与,来一个内部讨论会。

 


三位讲师和小伙伴们围坐在一起,探讨了不少有意思的问题。MySQL方面的更多一些,从并行复制到事务的监控,还听到一个比较奇怪的问题——查询某一行记录MySQL就会出问题。这类问题可以有一些思路,但很多时候不一定能给出一个明确答复,不过通过一个问题引申出很多不错的想法和见解,也是这个内部讨论精华所在吧。

 

关于Oracle,有一个同学碰到了DG在主库端的DDL导致备库hang住的问题,有一个隐含参数,但不确定补丁是否可行。之类问题的分析思路其实很重要,首先和mos上的bug不是完全符合,只是相似,那么通过隐含参数调整是不大推荐的。另外这个问题在测试环境中不可复现,所以提交了SR可能也不好处理,但可以一试。隐含参数的部分在Oracle中是一个很有意思的话题,Oracle的隐含参数非常多,开放的参数基本上只占到了10%的比例,10g到12c,开放参数从200多个增长到了400多个。

 

 

有意思的是MySQL的参数从5.0到5.7基本也是这个数量级。

 


通过这些变化,其实想引申出一些想法,就是在internal方面,Oracle的大门正在关闭,而在MySQL方面却有非常大的潜力。我认为Oracle的一个核心思想就是聚合、共享,在12c的PDB和RAC等就非常典型。而MySQL则截然相反,但是不能固步自封,你不能强迫自己用MySQL做各种复杂海量的统计分析,为什么不考虑用大数据的方式,而局限在关系型数据库呢?另外,大家对于MySQL internal的热情似乎不逊于几年前对于Oracle DSI文档的狂热。这从某种角度来看,是有些相似的。无论如何都要坚持下去,提高自己的竞争力。

 

 
一句最给力的评价

内部讨论会结束后,时间差不多6点多了,场地提供商无界空间的朋友给了我一句简短的评价,她说:“虽然听不懂你们在讨论的技术,但是我感觉很有意思,你们很有热情,就是实实在在讨论些东西,太实在了!”

这个评价太给力了,和我的预期不谋而合。

 

 
更多福利
  • PPT下载:登陆云盘:http://pan.baidu.com/s/1bQauxK 即可下载本次北京站沙龙PPT。

  • 演讲实录:讲师们的演讲实录将会陆续整理发布,密切关注DBAplus社群(dbaplus)订阅号哦~

最新评论
访客 2024年04月08日

如果字段的最大可能长度超过255字节,那么长度值可能…

访客 2024年03月04日

只能说作者太用心了,优秀

访客 2024年02月23日

感谢详解

访客 2024年02月20日

一般干个7-8年(即30岁左右),能做到年入40w-50w;有…

访客 2023年08月20日

230721

活动预告