2014中华架构师大会蓄势待发

会议官网

【大会介绍】
中华架构师大会又将与大家见面了!

2014年11月15日-16日,上海长城假日酒店,我们诚挚地欢迎您的参加!

自2010年11月首次举办以来,大会云集了国内水平最高的IT架构师、技术总监、项目经理、运维总监/经理、DBA经理、研发工程师等IT技术大牛,由最初的百人规模扩展到现今超千人的技术饕餮盛宴。大会一直受到业界广泛关注与赞誉,是目前华东与华南地区最受欢迎、人气最高的架构师技术交流盛会。本次大会将继续秉承分享IT最佳应用实践的宗旨,以“发现架构之美,实战为王”为主题,邀请国内知名互联网企业的资深架构师和工程师,探讨实下最热门的行业趋势与技术热点,分享架构在企业中的最佳实践。大会关键词:分布式文件系统、大数据、GO语言、自动化、分布式数据库、云计算架构设计等。

欢迎大家踊跃报名参会,大会期间将与各行精英面对面的交流,绝对让您不虚此行。

本届会议官方报名网站:http://meeting.zhdba.com

【大会详情】
会议名称: 2014中华架构师大会
会议时间: 2014年11月15日-16日
会议举办具体地址:上海恒丰路585号 上海广场长城假日酒店
票价: 免费
会议主办方:中华数据库行业协会
联系人:朱颖丹
电话:136 5197 9898
邮箱:zhuyingdan@zhdba.com

【主持人】

何为云数据库之云数据库产品的特点

何为云数据库

导读

当下国内环境,“云”等同于“骗”,但鉴于文章篇幅的限制,只探讨何为云数据库、云数据库产品的特点和重要性。

l  何为云数据库

 

云数据库是一种基于云的数据存储,提供数据的变更、查询、计算服务,对应用程序而言只需要提交一个数据库连接字符串即可访问的服务,且云数据库的用户不能直接控制运行原始数据库的主机。

master_pos_wait函数与MySQL数据库主从复制切换

背景

  主从切换是高可用MySQL架构的必要步骤(即使用不发生,也要有备无患)。一般设置为双M(M1、M2),假设当前状态为写M1,而M2只读,切换的大致流程如下:

1、  停止应用写M1,将M1设置为只读
2、  检查M2的slave status直到赶上M1
3、  将M1设置为可写

其中在第2步细化为
a)       在M1上show master status;得到binlog位置P,因为已经设为只读,不会变化

全球级的分布式数据库 Google Spanner原理

Google Spanner简介

Spanner 是Google的全球级的分布式数据库 (Globally-Distributed Database) 。Spanner的扩展性达到了令人咋舌的全球级,可以扩展到数百万的机器,数已百计的数据中心,上万亿的行。更给力的是,除了夸张的扩展性之外,他还能同时通过同步复制和多版本来满足外部一致性,可用性也是很好的。冲破CAP的枷锁,在三者之间完美平衡。

Spanner是个可扩展,多版本,全球分布式还支持同步复制的数据库。他是Google的第一个可以全球扩展并且支持外部一致的事务。Spanner能做到这些,离不开一个用GPS和原子钟实现的时间API。这个API能将数据中心之间的时间同步精确到10ms以内。因此有几个给力的功能:无锁读事务,原子schema修改,读历史数据无block。

Transfer在MySQL数据库双主同步架构中的应用

有同学讨论到Transfer能否支持双主结构,答案是支持的,这里简要描述下。

背景

       Transfer既可以当作主从库之外的工具来用,也可以本身充当slave的角色。本文分别描述在这两种使用场景下的部署结构和切换动作。 

Slave模式

a)      结构

这个就是最简单的双主啦,Transfer呢?代码直接写到这两个Master里面啦,所以他们就是Transfer.

MySQL多线程同步MySQL-Transfer介绍

一、关于Transfer

MySQL-Transefer(下称Transfer)是一个基于MySQL+patch后得到的主从同步工具。
其主要目的是为了解决原生版本的主从同步里,从库是单线程apply主库的binlog,导致的延迟。

最近完成测试的版本将multi-master (by P.Linux)合并到Transfer中并针对支付宝的应用需求做了定制性能改进。

这里做一个已经完成的完整功能介绍。

弃用NoSQL数据库 CouchDB再见了

【导读】

2012年5月10日,Sauce Labs公司的首席架构师Steven Hazel,写了一篇关于弃用NoSQL数据库CouchDB产品,介绍他们将Couch数据库的数据迁移到MySQL数据库平台中。

在Sauce Lab(酱油实验室)里,我们刚刚庆祝完成一个重大项目—将最后的CouchDB数据库转变为MySQL数据库,以提高服务正常运行时间和可靠性。 由于大部分无故停机的是由于CouchDB数据库宕机引起的,因此完成这种迁移是我们一个重要的里程碑。

CouchDB数据库开始时,是一个非常宝贵的经验,在1.2版本时它的可靠性还是可以的。 但我们的服务对可靠性要求非常高,于是最终决定:这种转变是前进中最有效的方式。

一旦决使用MySQL(具体而言,是Percona的基于InnoDB存储引擎的XtraDB存储引擎,),我们就重构了数据库抽象层,并迁移了所有各种类型的数据库。 在过去几个月,迁移完成后,我们的服务正常运行时间大大提高了。

这篇文章介绍了我们使用CouchDB数据库的经验,以及在哪里遇到了麻烦。我也谈了这方面的经验,如何影响了我们对NoSQL数据库的整体观点,以及在熟悉了NoSQL数据库后,如何积极权衡对MySQL数据库的安装配置。