数据库集群搭建 mysql分布式集群的搭建方案
大家好，今天来为大家解答数据库集群搭建这个问题的一些问题点，包括mysql分布式集群的搭建方案也一样很多人还不知道，因此呢，今天就来为大家分析分析，现在让我们一起来看看吧！如果解决了您的问题，还望您关注下本站哦，谢谢~
淘宝的数据库怎么搭建
我们也了解到，现在淘宝的整个的数据库团队在逐渐的把一些数据库从Oracle迁移到MySQL，然后呢，把一些服务器由小型机转到PC server，那你们整个转变的动机是什么?
主要是因为业务压力给了我们最大的动力。07年我来到淘宝的时候，当时只有三个主要的数据库，全部在小型机和存储上面。以当时的压力来看，它跑起来是非常顺利的，而且大家也知道小型机它从Unix操作系统到硬件，稳定性都会比PC server其实要高很多，当时的情况下淘宝用小型机是一个非常自然的选择。
从07年开始淘宝的业务量保持每年自然翻一番的增长，数据库质量感觉到非常大的压力。那么前端业务量增长一倍，在数据库上有可能增长是好几倍，它有一个放大效应在里边。当时我们第一步能够想到很自然的架构，就是把三个数据库拆成更多的数据库，或每一个数据库支持一个比较单一的业务。比如用户、商品和交易，都会分成独立的数据库，然后放到独立的小型计算中去，这是我们08年做的很大的事情就是垂直拆分，然后08年的业务我们就顶住了。
当时我们就预估09年、10年会有更大的压力增长，这个时候我们应该怎么办？当时我们从业界能看到很多的经验分享，包括eBay、亚马逊这些国外的大公司，他们的经验分享里面，水平拆分是我们数据库涨到一定程度后的架构选择。我们从Oracle到MySQL转移，主要是用水平拆分，这是我们未来的一个弱点，那水平拆分后机器、数据库的数量都会多很多，那Oracle它本身的成本也是我们考虑的一个重要因素，所以当时从成本考虑的话，那个时候我们自然会选择用MySQL数据库。
给我们再简单总结一下这几年，淘宝整个数据库的演变过程?
刚才说到08年我们做完垂直拆分以后，09年到今年我们主要做的工作其实就是水平拆分。今年在十月份之前我们全部完成了淘宝最核心的三个系统：交易数据库、商品数据库和用户数据库的水平拆分。所以到“双十一”之前，在我们内部采访中，我一直跟采访人员说，当时数据库情绪稳定。基本上我们没有做什么事情，只是在不停的看报表，看数据，然后很开心的看到交易曲线以超过45度的趋势往上涨。
那前期还是做了非常完善的准备。据我们了解在整个从小型机到PC server的迁移，包括从Oracle到MySQL数据库的迁移，你们在做这个事情的时候，都做过好几个月的压力测试。你讲讲这个背景和故事。
是这样的，今年我们年初决定，我们商品库从小型机迁到PC server上面去，这是淘宝压力最大的一个数据库，当时是用四台小型机加两个高端存储来支撑的。要把这么大一个数据库进行迁移，我们心里面也是没有底的，因为不知道要多少台PC server能够支撑，需要什么样的配置来支撑这个压力？当时我们能够想到一个很直观的想法就是模拟线上完全一样的压力，甚至加上几倍的压力来测它的极限值。
我们和开发团队、我们的性能测试团队，加上DBA团队和ops团队，成立了一个非常大的项目组，然后做了接近两个月的性能测试，在整个测试过程中发现了非常多的问题，包括我们给Oracle、MySQL等厂商都提交了很多Bug，有些Bug也得到厂商回应，进行修复。
那整体的转变的过程到现在进行到了什么样的程度？包括你在整个转变的过程中遇到哪些问题?
我们现在最核心的用户数据库今年已经彻底完成了从小型机、存储和Oracle切入到PC server加MySQL的架构。
我们内部有一个提法叫做去O、去I、去E，其实就是我们要从高端硬件Scale up模式到低端硬件的Scal out水平扩展的模式，这是淘宝内部最大最核心的系统，今年已经顺利完成了全部区的水平扩展。其他几个系统，比如说交易和商品已经完成了一部分，完成了水平拆分的一部分，但是没有达到我们希望的进度，这可能是明年我们需要做的事情。
在转型过程中主要遇到哪些问题?
让我们觉得比较大的问题就是我们从可靠的小型机迁移到大规模，大数据量的PC server上来，从架构上就对我们就是一个非常大的挑战。大家都知道，每一个PC server的稳定性肯定和单台小型机会有一定的差距，再加上我们一个机群有可能是32台或者64台PC server。每一台PC server即使有四个9的可用性，但如果我们整个系统合在一起，可能它最后的两个9的可用性都达不到。这就需要我们从软件层、架构层要做非常多的改进，能够要让单点的一些失效对整体的系统不造成任何影响，因为我们和架构部门、开发部门一起做了很多事情，才能保证我们的集群稳定上线。
其实“双十一”这个时间应该说是对过去的技术转变的检验，现在回头来看，这个检验的结果怎么样?
当时是有点提心吊胆的，之后又觉得相对来说今年我们做的很多事情还是非常成功的。但是现在再回头仔细想想还是有点后怕，“双十一”那天的凌晨零点不是有一次Ipad的秒杀吗，当天晚上我们都在线上观察数据，在零点的一瞬间，就看到所有数据库指标已经达到了以前正常时候最高峰的指标，有些甚至还超过了。
当天晚上睡觉的时候心里就有点在打鼓：才零点就这个样子了，明天下午明天晚上最高峰的时候我们应该怎么渡过？所以第二天早上八点多的时候我们一进到指挥部里面就看到所有的指标，包括CDN的指标、各个业务线的指标、数据库的指标都是噌噌的往上涨，这时心里面其实是很忐忑不安的。
但是我们比较放心的是这三大核心系统，商品、用户和交易，在我们今年所有的水平扩展项目做完了以后，比如说商品功能做完了以后，从我们的机械压测里面它是有十倍的流量的，所以当天百分之一百，百分之两百的流量基本上对数据库没有造成太大的影响，所以当时还是很开心的看到这个指标快速的往上涨，希望交易能够通过10个亿、20个亿，我觉得都是能够承受的。
那对于整个数据库架构的演进下一步有什么打算?
下一步其实就是刚刚说的我们有几个核心系统还没有完全的做到这个水平扩展，加上“双十一”那天我们还是有一个小惊险：我们有一个数据库，跟交易核心有一点点联系的，但它还是放在小型机上面，当时已经提前为它准备了百分之一百的余量，就是说它可以承担平时最高压力的两倍。
但是那天已经达到平时最高压力的1.8倍左右的时候，把我们吓出了一身冷汗。如果当时淘宝的交易最高峰的流量再增长20%的话，有可能数据库就会到瓶颈了。所以我们明年是要把更多这种Scale up能够看到天花板的数据库全部要拆分成水平库存这种数据库。
那你刚才所提到的去Oracle，去小型机，去高端存储，这个“三去”的整体思路给淘宝网带来了哪些经济上的效应?
当时我们知道小型机和存储的价格是非常昂贵的，还是拿我们刚才说压力最大的商品数据库举个例子，当初我们数据库是用了四台高端的小型机，两套高端的存储，成本加起来起码都是三千万以上。那目前我们用的是32台PC server来搭建的一个机群，价格也就是300万~500万的级别。相对来说我们做完这个事情以后，解决了两三千万的硬件成本。
这样来讲，整体的经济效益还是非常不错的。但是其实刚才我们在前期沟通的时候也提到，你要从Oracle转到MySQL，包括从小型机转到PC server，其实里面还是会遇到蛮多问题的，包括它的不稳定性等等，那对于这一方面你有没有什么经验可谈?
在这一方面，我觉得有两个很重要的因素。第一个是我们需要和我们的开发前端应用架构部门能够紧密的合作，能够让我们的应用融入刚才说的整个机群的单点失效和容灾的问题。都需要我们和架构部门一起来考虑的；第二个比较大的经验就是目前我们在做的，深入研究MySQL的源代码。我们从研究和压力测试的过程中，发现MySQL它本身代码的一些缺陷，可能在高并发大压力下会有很多隐藏的Bug。
在我们最近的这次测试当中，我们还发现了Facebook发布的FlashCache二级缓存的软件，当时我们是测出它一个非常大的Bug：并发压力非常大的情况下，它会导致MySQL成为一个僵尸进程。我们发现了以后，很快反馈给Face book，然后Face book很快就修复了这个问题，这也是我们对使用开源软件带来更大的一个信心，就是开源能够在全球得到更多的支持，大家都能够从原代码层面来解决更深层次的一个问题。
我想这也可能是淘宝技术团队现在那么开放，那么注重开源的动力之一。那如果说想对MySQL的一些核心代码做编译，就需要对人才的储备，包括各方面资源整合的要求还是蛮大的，那你在这方面有没有什么感触?
说到人才这个话题，08年的时候，淘宝当时准备大规模的往MySQL方向上转，我们内部也是有一些置疑的声音。他们说淘宝DDA团队以前都是在Oracle方面比较专精，在业界来说，淘宝的DDA团队在Oracle方面更加有名气一些。所以我们内部有置疑的声音。就是说你们有MySQL专家吗，MySQL出问题了以后能很快的解决吗？所以从08年到现在，我们慢慢的一路走过来，内部培养了很多的MySQL的人才，包括这几年我们的应届生的成长，再加上我们从外部招到一些专家，我们对MySQL的理解已经越来越深。
刚才说到，我们已经能够给MySQL打Patch，已经能够给MySQL report这些Bug。到现在为止，我觉得MySQL的成长已经达到了非常高的一个程度，我们对MySQL已经越来越有信心，但是未来淘宝的MySQL肯定是要做得越来越大的，淘宝还有很多小型机上面扩展不太容易的系统需要迁移到可扩展的机群上面来，但我们也希望业界能够有更多的MySQL伙伴加入我们，和我们一起来做这么一件非常有意义的事情。
我想能够加入到淘宝的技术团队，去经历那么多有大交易量的技术实践还是非常宝贵的。另外一个问题就是虽然说现在我们用的越来越多的是MySQL，但是现在大家也知道MySQL已经被Oracle收购了，那对像淘宝这样的团队有什么影响呢?
大家都知道MySQL其实是基于GPL的协议来开源的软件，那淘宝在使用过程中，前期是已经考虑到一些风险。所以我们所有的MySQL都是自己来做编译做优化的，而且我想MySQL被Oracle收购了以后，现在看起来Oracle应该是给MySQL在开发这方面是提供了更大的帮助，像之前在Sun的时候，MySQL的版本相对来说是比较混乱的，包括我们现在在用的5.0和5.1的正式版本，最近还有包括开发方面就还有两个，一个6.0，一个5.4，这些特性会互相交织在一起，让我们选择的时候也有点不知道到底选哪个版本会更好一点。但现在Oracle收购MySQL以后，他把5.4跟6.0这些版本已经合成了一个比较规范的5.5的版本，并且为它制订了很好的一个milestone15：31，未来要怎么发展这个里程碑，M1、M2、M3、M4这种发展方向，而到现在为止这个5.5已经发展到5.6、5.7的版本，而且已经是IC版本了，很快就要GA了，那我想这对于MySQL来说应该是一个好消息。我们可以用到更多更稳定的新特性， 5.5版本里有几个新的特性是我们非常关注的，比如Google已经达到英文15：57这个pach，所以我们觉得对我们未来的这个MySQL这个系统非常有用的一个功能。那我们也等着Oracle的5.5这个版本能够尽快的GA出来。
Docker搭建高可用Mysql数据库集群有什么用
在Docker上搭建高可用MySQL数据库集群有以下几个好处：
高可用性：集群中每个MySQL节点都可以接收读写请求，当一个节点出现故障或宕机时，其他节点可以接替它的工作，确保了数据库的高可用性。
负载均衡：集群中每个MySQL节点可以根据负载情况来分配读写请求，均衡每个节点的负载，提高整个系统的性能和稳定性。
数据备份：集群中的每个节点都可以备份其他节点的数据，确保数据的安全性和完整性，一旦出现数据丢失或者损坏的情况，可以及时进行恢复。
扩展性：集群可以方便地扩展到更多的节点，以适应业务增长和访问量的提高，同时也能够保证系统的性能和可靠性。
总之，使用Docker搭建高可用MySQL数据库集群可以提高系统的可用性、可扩展性和稳定性，同时也能够更好地保护数据安全和完整性。
如何搭建数据湖架构
EdoInteractive在几年前遇到一个大问题：公司使用交易数据来帮助零售商和餐馆进行个性化促销，但其数据仓库没有足够时间去处理所有的信用卡和借记卡交易数据
“我们要花费27小时来处理每日的数据量，”Edo主管基础设施和信息系统的高级副总裁TimGarnto说道：“所以在2013年，我们放弃了现有的基于PostgreSQL的关系型数据库系统，使用了Hadoop集群作为公司的数据湖架构。”
Garnto的团队一天中需要收集5000多万条美国零售交易数据，并分发到20个节点的集群中,这些节点运行在Cloudera的Hadoop分布式机架上，使用Pentaho的数据集成工具。从银行和信用卡公司收集到的数据，会被传入设计好的预测模型中，以确定个体持卡人所需的优惠券。Edo的业务伙伴每周通过电子邮件发出优惠券，这些优惠券会在产生对应消费时生效。
每日的数据构建时间缩减到大约四个小时，Garnto表示，根据正在运行模型的复杂性，Edo的数据分析师能“在几分钟或几小时内完成他们的工作。而以前，他们可能累的要死。
但数据湖上并不总是阳光灿烂，一帆风顺的。起初，Edo只有一个员工具有HadoopMapReduce编程框架的经验。公司联合Chicago总部和Nashville分部，对其他员工进行Hadoop技术内部培训，但后来这使得他们不得放弃了熟悉的数据查询方式。“我们花了很多时间更新这一过程。”Garnto说。
创建一个保证原始数据一致性和生成标准化分析数据集的两步程序也需要花时间去解决。目前拥有包含450亿条记录(总共255TB的数据)的集群，已成为Edo业务操作的核心，对于这个集群，Garnto需要小心管理，谨慎添加新的Hadoop生态技术。否则，对公司某个部分的调整可能会影响整个系统对其他部分的工作处理。
数据湖使实时分析成为了可能
Webtrends公司是另一家数据湖的使用者，该公司收集并处理网站、手机、物联网上的活动数据。这家位于波特兰的公司于2014年7月部署了基于Hortonworks的Hadoop集群，目前正在试用阶段，计划在2015年初完全实现。它最初只支持了一个叫Explore的产品，让企业营销人员做客户数据的专项分析。Webtrends产品架构主管PeterCrossley表示，每个季度大约有500TB的数据添加到60个节点的集群中，现在总共有1.28PB。
随着时间的推移，Webtrends计划使用Hadoop平台代替自有的数据网络附加存储平面文件系统。Crossley表示，使用ApacheKafka消息队列和自动化脚本处理技术，互联网点击流数据可以涌入集群和并在20至40毫秒内做好分析准备工作。因此，报表和分析过程几乎可以在瞬间开始，这比老系统快得多。Hadoop集群还支持进阶分析，且能降低25%到50%的硬件成本。
Crossley表示，采用数据湖概念需要公司内部在管理和使用Webtrends为客户收集的信息时做到“思路上的转变”。之前，该公司主要使用数据存储构建通用报表。但是，一个数据湖与其说是一个真理，不如说是真理的来源，在其之上，您可以构建多个数据集以供不同的分析用途。
Webtrends也不得不认真考虑其数据湖的架构和数据治理过程，以防止Hadoop集群变成“数据沼泽”，正如Crossley所说。刚刚进入系统的原始数据结构十分松散(+微信关注网络世界)，但是应该有非常严格的规则来规定其应该是什么样子。此外，他的团队已经将集群分成三个不同的层次：一个用于原始数据，第二个用于日增量数据集，另一个用于存储需要被纳入的第三方信息。基于不同的数据集细节，每一层次都具有自己的数据分类和治理策略。
对你的数据保持控制
Razorsight公司CTOSurenNathan还指出，建立和管理一个Hadoop数据湖需要具备良好的纪律性和组织性。否则系统很快就会变成一个失控的垃圾场，就像一个由很多文件组成的SharePoint，没有人知道如何找到这些文件。
Razorsight为电信企业提供了一组基于云的分析服务，2014年第二季度开始使用运行在Hadoop集群上MapR技术。客户组、操作和网络数据通过自有工具被输入到系统中，通过Spark引擎的处理后，由Razorsight数据科学家进行分析;集群具有五个生产节点和120TB的存储容量。
和Webtrends类似的，Razorsight数据湖被分割成三个分区。在Razorsight的案例中，一个数据湖能够存储不到六个月的数据，另一个包含旧的但仍然活跃的数据，第三则存储不再使用的但需要保留的信息。目前，在这两个活动区域中有超过20TB的数据。为了保证系统工作平稳，Razorsight招聘了具备分布式系统的数据治理和开发经验的新员工，同时也培训现有员工使用Hadoop，Spark和相关技术的能力。
目前是迁移到新平台的阶段。每TB大约花费2000美元，Hadoop集群成本仅仅是公司之前所部署的IBMNetezza数据仓库系统的十分之一。但Nathan表示，Razorsight首先建立专门用于数据存储的集群，然后再进入处理和准备阶段。因为Netezza硬件和IBMSPSS分析软件之间存在的紧密联系，分析建模和数据可视化仍会存在于旧的系统中。建模将保持现状，但Nathan预计到今年年底，将可视化层和Razorsight分析结果数据转移到数据湖架构中。
转自网界网：http://software.cnw.com.cn/software-database/htm2015/20150709_321300.shtml
来自TechTarget中国的作者：CraigStedman分享
转自网界网：http://software.cnw.com.cn/software-database/htm2015/20150709_321300.shtml
mysql分布式集群的搭建方案
不是很理解，比如说你3台搭建分布式，你通过什么方式区分库表？假设每台服务器上部署一个mysql实例，那你怎么把数据分布到3个mysql里面？是每个mysql里面存不同的表么？如果这样，就还可以接受。这块问题不是很大。
第二个问题，你的HA主备，意思是说两个分布式互为主备？那怎么备份，怎么切换？
其实按照你想要达到的目标。应该是每两台互做主备，形成3对主备库，然后这3对再组建一个分布式集群。
其实和你要做的可能差不多，不过逻辑上还是有差异的。HA你准备怎么做？keepalived？
另外，咨询一下，你的分布式是通过什么来实现，不同业务访问不同的数据库，每个库存不同的表？还是相同的表分布在不同数据库？
看你服务器的配置如何，其实我觉得一般来说拿3台来做备机有点浪费，如果配置允许，可以考虑做成6套mysql主备的分布式集群。
通过交叉互备实现硬件的最大利用。下图是我们之前用4台服务器做的一套集群方案。
如果还有其他问题可以和我联系。
好了，关于数据库集群搭建和mysql分布式集群的搭建方案的问题到这里结束啦，希望可以解决您的问题哈！