分库分表，顾名思义就是把原本存储于一个库的数据分块存储到多个库上，把原本存储于一个表的数据分块存储到多个表上。那么关于分库分表，你了解多少呢？接下来，我们将从什么是数据分片及如何进行分片两方面对DDM分库分表做一个阐释。                什么是数据分片分片是解决数据库存储容量限制的直接途径。分片包括垂直分片与水平分片两种方式。垂直分片垂直分片又叫纵向分割，即以逻辑表为单位，把原有数据库切分成多个数据库。切分后不同的表存储在不同的数据库上。垂直分片与业务架构设计有密切的联系。比如从业务领域对系统进行架构优化，分成多个子业务系统，各个子业务系统耦合度较低。子业务系统间以接口方式进行数据通信和数据交换。垂直拆分后业务清晰，拆分规则明确，系统之间容易整合与扩展。一般用于数据库上层架构设计。                                             垂直分片示意图 水平分片水平分片又叫横向分割，即以逻辑表中的数据行记录为单位，把原有逻辑数据库切分成多个物理数据库分片，表数据记录分布存储在各个分片上。水平分片主要用业务架构无法继续细分，而数据库中单张表数据量太大，查询性能下降的场景。通过水平分片，即解决单库容量问题，同时提高并发查询性能。水平分片示意图 DDM实现了自动水平分片，应用无需关心某个数据该存储在哪一块分片上。对逻辑表水平分片需要依据一定的分片规则，例如一个订单跟踪系统，我们选取订单号(OrderId)作为拆分键，分别对“订单流水表”、“订单详情表”以及“物流跟踪表”进行水平拆分，拆分规则为对键值Hash后求模，则分片计算规则如下：H(Key(OrderId)) = Hash(Key(OrderId))%N其中，N表示一共有N个数据分片，H(Key(OrderId))表示该订单经过订单号Hash并求模后存储的分片编号。分片后数据存储示意图  如何进行分片在分布式数据库中，可以通过分库分表存储方式，轻松解决大数据量单表容量达到单机数据库存储上线的瓶颈。但是分库存储后，需要尽量避免跨库JOIN操作带来的性能与资源消耗问题。因此创建逻辑库和逻辑表时，需要根据实际情况确定：1、逻辑表分不分片？DDM逻辑表支持全局表、分片表、单表三种类型。用户可以按照数据表的实际使用需求，选择最合适的逻辑表类型创建。单表只在第一个分片创建表以及存储数据，全局表在每一个分片创建表并且存储全量数据。分片表在每一个分片创建表，数据按照拆分规则分散存储在分片中。2、按什么规则分？逻辑表的拆分键选择非常重要。建议按实际业务场景选择拆分键，不同逻辑表，如果具有E-R关系，建议选择相同字段做拆分键，避免跨库JOIN操作。在实际使用中，有以下建议供参考：数据量在1000万以下的表，不建议分片。通过建立合适的索引，采取读写分离策略，单表也可以很好的解决性能问题。数据量在1000万以上的表，建议分片。将数据分片存储后，既能解决单张表容量过大带来的性能瓶颈，同时提高并发支持。注意要选择合适的拆分键，提前做好规划。业务读取尽量少用多表JOIN，同一个事务避免跨分片。查询条件尽量带上拆分键，避免全分片表扫描。 数据库中间件DDM将底层数据库存储引擎以集群方式管理起来，用户使用非常方便。应用程序不需要关心具体有多少分片。类似操作单机数据库，用户通过DDM管理控制台进行数据库运维，使用JDBC等驱动服务或SQL客户端连接数据库，进行数据读写。想要了解更多，欢迎点击分布式数据库中间件DDM查看。

本贴内容节选自华为云帮助中心的分布式数据库中间件（DDM）服务的产品介绍 背景随着业务增长，逻辑库存储空间不足，并发压力较大。 解决方案此时可对DDM实例逻辑库进行平滑扩容，通过增加RDS实例来提高数据存储能力与并发支持能力。在不中断应用服务的情况下，通过新增RDS实例，扩展数据库存储空间。扩容除了解决数据存储容量瓶颈，还能通过增加并发计算能力间接提升数据库性能。通过DDM管理控制台操作即可完成扩容，应用无需改造，扩容进度支持可视化跟踪。 平滑扩容平滑扩容是一种水平扩容方式，通过增加RDS实例的数量来提升总体数据存储容量，把分库平滑扩容到新增加的RDS实例上，保证所有的数据都是均衡分布在每个分库上，降低单个RDS实例的处理压力。 平滑扩容原理如下图所示。 18946平滑扩容原理 逻辑库平滑扩容实践操作场景逻辑库扩容涉及到数据迁移。具体分以下情况：1、所有全局表将复制一份，存储到新增RDS实例的对应分片中。2、分片表数据将会重新分配和存储。3、单表存储在默认分片上，扩容过程无需迁移单表数据。说明：RDS存储空间不足时，建议对逻辑库下的某一RDS实例进行磁盘扩容，扩充RDS实例存储空间。并发压力较大无法满足业务需求时，建议按照以下操作增加RDS实例，进行平滑扩容。“拆分算法”为“Range”的逻辑表在进行平滑扩容时，只在新的分片上创建物理表，不做数据迁移。扩容成功后，用户需要手动修改“Range”表的分片规则，加入新分片的规则。 操作步骤 [*]登录管理控制台。 [*]在导航上选择“数据库 > 分布式数据库中间件”，进入总览页面。 [*]单击左侧菜单栏的“DDM实例管理”，进入“DDM实例管理”页面。 [*]单击DDM实例名称，进入实例基本信息页面。 [*]在实例基本信息页面，选择“逻辑库管理”选项卡，查看DDM实例逻辑库。 [*]在需要扩容的逻辑库右侧操作栏单击“平滑扩容”。 [*]在“平滑扩容”弹出框左侧勾选需要扩容的RDS实例，单击“确定”。可在“逻辑库管理”页面查看扩容进度，扩容过程大概需要5-30分钟，具体时长与实际需要迁移的数据量相关。当“逻辑库状态”为“运行中”时，表示扩容成功，“已使用RDS”列将会呈现新扩容的RDS实例。 说明：只有逻辑库状态为“运行中”才能进行平滑扩容。一个DDM实例内，只允许同时对一个实例逻辑库进行平滑扩容操作；不同的DDM实例内，可以同时扩容实例逻辑库。 注：平滑扩容使用限制如下：1、RDS实例与DDM实例需要在相同VPC，且RDS实例没有被其它DDM实例使用。2、逻辑库下必须有表才能进行平滑扩容。3、实例存在节点故障情况下不能进行扩容。4、一个DDM实例内，只允许同时对一个实例逻辑库进行平滑扩容操作；不同的DDM实例内，可以同时扩容实例逻辑库。5、不允许使用正在扩容中的RDS实例进行建库建表操作。6、最多仅支持扩容50个RDS实例。7、扩容最大规格为：每个分片不超过20张表。每张表不超过800万数据。 以上就是关于数据库秒级平滑扩容的实践方案，想要了解更多，欢迎点开分布式数据库中间件DDM查看。

本帖最后由 小柴不加胡 于 2018-6-21 17:21 编辑随着数据量不断增大，传统的架构模式难以解决业务量不断增长所带来的问题，特别是在业务成线性、甚至指数级上升的情况。此时我们不得不通过水平扩展，把数据库放到不同服务器上来解决问题，也就是我们说的数据库中间件。 作为数据库中间件，分布式数据库中间件DDM将底层数据库存储引擎以集群方式管理起来，用户使用非常方便。应用程序不需要关心具体有多少分片。类似操作单机数据库，用户通过DDM管理控制台进行数据库运维，使用JDBC等驱动服务或SQL客户端连接数据库，进行数据读写。 17948DDM服务的业务架构图示 分片是解决数据库存储容量限制的直接途径。分片包括垂直分片与水平分片两种方式。垂直分片垂直分片又叫纵向分割，即以逻辑表为单位，把原有数据库切分成多个数据库。切分后不同的表存储在不同的数据库上。垂直分片与业务架构设计有密切的联系。比如从业务领域对系统进行架构优化，分成多个子业务系统，各个子业务系统耦合度较低。子业务系统间以接口方式进行数据通信和数据交换。垂直拆分后业务清晰，拆分规则明确，系统之间容易整合与扩展。一般用于数据库上层架构设计。 17949垂直分片示意图 水平分片水平分片又叫横向分割，即以逻辑表中的数据行记录为单位，把原有逻辑数据库切分成多个物理数据库分片，表数据记录分布存储在各个分片上。水平分片主要用业务架构无法继续细分，而数据库中单张表数据量太大，查询性能下降的场景。通过水平分片，即解决单库容量问题，同时提高并发查询性能。 17951水平分片示意图 DDM实现了自动水平分片，应用无需关心某个数据该存储在哪一块分片上。对逻辑表水平分片需要依据一定的分片规则，例如一个订单跟踪系统（见上图），我们选取订单号(OrderId)作为拆分键，分别对“订单流水表”、“订单详情表”以及“物流跟踪表”进行水平拆分，拆分规则为对键值Hash后求模，则分片计算规则如下：H(Key(OrderId)) = Hash(Key(OrderId))%N其中，N表示一共有N个数据分片，H(Key(OrderId))表示该订单经过订单号Hash并求模后存储的分片编号。 17952分片后数据存储示意图 路由分发路由分发与水平分片同为DDM的基础功能。在分布式数据库中，路由的作用即将SQL语句进行解析，并转发到正确的分片上，保证SQL执行后得到正确的结果，并且节约QPS资源。例如：订单支付系统包含了shard0、shard1、shard2三个分片，订单号2017010112345678的订单数据存储在shard0分片上，则应该将以下语句路由分发到shard0分片上执行。select Customer, OrderStatus, CreateDate from Orderwhere OrderId = '2017010112345678'; 如果同时路由到shard0、shard1、shard2三个分片，会造成多余的查询，浪费资源；如果路由到shard1、shard2分片，则得不到正确的返回结果。DDM对单张表的路由解析流程如下： 17953单张表的路由解析流程读写分离数据库中对计算和缓存资源消耗较多的往往是密集或复杂的SQL查询。当系统资源被查询语句消耗，反过来会影响数据写入操作，进而导致数据库整体性能下降，响应缓慢。因此，当数据库CPU和内存资源占用居高不下，且读写比例较高时，可以为数据库添加只读实例。 添加只读实例的作用有以下：1、将查询非事务性查询SQL路由到只读实例中执行，主实例上执行事务性SQL，在很大程度上缓解主实例上的S锁与X锁的竞争。2、对只读实例上的表可配置不提供事务支持的数据库引擎，进而提升查询效率。3、增加只读实例，也相当于数据库横向扩展，直接增加负载能力，同时增加数据冗余，确保数据库高可用。DDM服务实现了自动读写分离，用户购买了RDS只读实例后，将只读实例信息同步到DDM中即可，无需再做其他配置。同时，DDM支持用户在SQL中自定义读写分离策略，具体用法请参考如何实现读写分离。 17955读写分离示意图 平滑扩容随着业务增长，逻辑库存储空间不足，并发压力较大，此时可对DDM实例逻辑库进行平滑扩容，通过增加RDS实例来提高数据存储能力与并发支持能力。平滑扩容是一种水平扩容方式，通过增加RDS实例的数量来提升总体数据存储容量，把分库平滑扩容到新增加的RDS实例上，保证所有的数据都是均衡分布在每个分库上，降单个RDS实例的处理压力。平滑扩容原理如下图所示。 17956平滑扩容原理 以上就是对分布式数据库中间件DDM实现原理的浅析，目前华为云DDM推出了免费体验活动，想要了解更多，欢迎前往分布式数据库中间件查看。

又到了一周一次的华为云视界直播~ 本期华为云视界直播将邀请到华为云分布式数据库中间件的专家为您详细阐述华为云分布式数据库中间件的前世今生，干货满满的技术揭秘，期待您的现场参与体验！ 直播链接：http://zhibo.huaweicloud.com/watch/1971154 或扫描二维码手机观看 17297 随着互联网时代的到来，数据量呈指数级别地飞速上涨。我们的系统所需要支持的用户数，很可能在短短的一个月内突然爆发式地增长几千倍，MySQL等数据库从GB级飞速上涨到了TB级。伴随业务的信息化发展、海量并发、海量存储等现象使得传统的数据库方案面临新的困境： ● 单机数据库容易产生容量与性能瓶颈● 传统的分区分表或分库方案限制太多● 单机数据库服务器成本高昂 如果在这爆发的关键时刻，系统不稳定或无法访问，那么对于业务将会是毁灭性的打击。面对海量数据洪流，华为云推出了分布式数据库中间件服务DDM，DDM是专注于解决数据库容量、性能瓶颈和分布式扩展问题的中间件服务，提供分库分表、读写分离、弹性扩容等能力，应对海量数据的高并发访问场景，有效提升数据库读写性能。 DDM的核心优势如下： 自动数据分片：将数据自动按规则拆分数据到指定的分片中，并提供路由分发和自动聚合能力。 透明读写分离：自动完成透明读写分离，提高读操作的并发性能，支持一键添加只读实例轻松提升读性能。 卓越并发性能：提供 PB 级数据量访问，十倍于单机数据库连接数，支持百万级高并发。 平滑弹性伸缩：一键添加 RDS 实例，DDM 自动完成数据的重新分布。 本期直播议程：2018年6月14日16:00-16:45 深度解析华为云分布式数据库中间件16:45-17:00 线上互动问答

本帖最后由 小柴不加胡 于 2018-6-5 11:02 编辑进入云计算时代，传统的数据库在性能和容量等方面已无法满足企业的要求，随着数据量的不断骤增，易于扩展、拆分的数据库解决方案对于企业的云化转型更是显得尤为重要。为使企业应用上云更简单，分布式数据库中间件DDM（Distributed Database Middleware）专注解决企业在上云过程中面临的的数据库瓶颈难题，不但更能轻松满足水平拆分、扩容、读写分离等业务需求，同时也比传统方案更具性价比。接下来让我们一起零距离解密DDM。 DDM是什么？DDM专注于解决数据库分布式扩展问题，它突破了传统数据库的容量和性能瓶颈，实现海量数据高并发访问。DDM提供了对应用透明的数据库读写分离、自动的数据分片、灵活的弹性伸缩等分布式数据库能力。 DDM如何定义读写分离？从数据库的角度来说，对于大多数应用来说，从集中到分布，最基本的一个需求不是数据存储的瓶颈，而是在于计算的瓶颈，即SQL查询的瓶颈，在没有读写分离的系统上，很可能高峰时段的一些复杂SQL查询就导致数据库系统陷入瘫痪，从保护数据库的角度来说，我们应该尽量避免没有主从复制机制的单节点数据库。传统读写分离解决方案耦合应用代码，扩容读节点或修改读写分离策略等需要修改应用代码，升级应用程序，非常复杂。DDM实现了透明读写分离，应用实现读写分离不需要修改代码，为了保证读一致性， 默认情况在事务中的读全部分发到主节点。事务外的读分发从节点。写分发主节点。在应用程序需求复杂时，DDM提供了hint可由程序自主控制sql的读写分离逻辑。此外，后端DB如果部分节点故障了，DDM会自动摘除故障节点，自动进行主从切换，对应用无感知。16363 ( 附改造前后构架对比图) 应用在微服务架构下，服务会拆分的比原来更多，与数据库的连接数也会增加很多，这是否同样是分布式数据库中间件需要解决的一个重要问题？对的。举个栗子，比如某应用的最大连接数是2000，未做服务化拆分前，应用程序独享2000个数据连接，假设拆分成100个微服务，那么为了保证总的连接数不超过MySQL的最大连接数，那么每个微服务能配置的最大连接数就是20.这对应用几乎是不可接受。市面上很多分库分表中间件如Cobar、Atlas等，对后端MySQL的连接池管理是基于分片来实现的，而不具备整个MySQL实例的共享互通，抗并发能力被严重削弱。而DDM是真正基于MySQL实例模式实现的，一个MySQL实例下的所有数据库共享一个连接池。这个对于分片来讲，能避免有些库的连接很空闲，有些库的连接不够用的情况，最大限度提高并行性。其中涉及到session级别的属性由DDM自动维护，应用程序无感知。 在这种共享模式下连接数有上限吗？DDM的前端连接与MySQL连接对比起来相对轻量级，可以相对轻松支持上万的连接。当然，为了防止单个用户滥用资源，支持设置前端最大连接数限制。16364( 附改造前后构架对比图) 在应用场景上，是否一定要用DDM的方式去解决？这里同样也有硬件升级、数据库自身的分区方案，该如何选择？硬件方案由于成本高和扩展性差的问题在这里就不谈了，而数据库自身的分区表方案，只能局限在一个库内，数据无法跨库跨实例，扩展方案有限，DB故障和调整都需要应用同步调整，运维难度剧增，升级维护工作量大，小型系统还好，对于大型系统不可接受，长期来看采用分布式数据库中间件是解决之道。 DDM如何做分片设计？对于分布式数据库中间件，业内普遍有以下两种做法，第一种，认为分片算法的选择对用户来说是一种心智负担，应该对用户完全隐藏，另外一种观点认为应该给用户完全自由去选择，比如一些开源软件，提供了十几种分片算法。DDM认为如果完全隐藏分片字段和分片算法的选择，可能会造成不必要的全表扫描，浪费资源，无法做到线性扩展。因为最了解业务的还是用户自己。分片算法过多的确会带来选择上的负担，有些算法存在主要是因为缺少平滑扩容存在的不得已而为之。DDM设计了三种标准分片算法，hash、range、list，后续酌情开放自定义算法。 能不能给大家详细介绍下这三种算法？1. hash：hash算法的特点的数据分布比较均匀，无热点问题，缺点是如果有针对部分范围的查询，需要全分片扫描。hash类数据扩容需要迁移数据，DDM有平滑扩容功能，所以这块不用担心。 2. range：数据按数字范围或者日期范围进行分片，针对范围的查询可以并行，但是缺点范围是单个范围可能会有热点问题，比如按日期最近一个月的数据操作会比较多，按范围就只其中一台或少量几台机器可以负担操作。范围分片在扩容时不需要迁移数据，只需要将新范围配置到新加的RDS即可。 3. list：枚举分片可以看做range的一个特例，在此不再赘述。 hash算法的设计？hash算法的设计，主要考虑到与平滑扩容的配合，采用二级映射分片规则，主要为了方便控制slot到实际dataNode的映射关系，而一致性哈希这里是算法固定。 与传统方案相比，DDM在扩容上有什么独特的优势？传统做法DBA手工迁移数据，要停机，影响业务，迁移过程可能会出错。业内很多中间件的实现扩容方式一般是按照整库迁移的方案，比如原先有8个分库，迁移只是将部分库整库迁移到新的RDS上，这样的弊端是分片个数并没有增加。DDM的做法是真正实现了数据重分布，按slot为单位迁移数据，迁移完成后保证数据的大致分布均匀。分片个数随着新增RDS而自动增加。DDM在操作上真正做到了自动化，实现了一键式迁移，迁移过程中切换路由、清理数据均是自动化完成，不需要用户时刻盯着再去操作。即使迁移中出现异常，也会自动回滚，保证迁移数据的一致性。迁移过程中不阻塞业务，只在切换路由时短暂中断写入操作，读操作正常，而且只影响到被迁移的那部分数据的写入，对其他数据完全没有影响。16365 ( 附迁移流程图) 在路由切换速度和内容准确性上DDM有哪些考虑？关于切换路由速度，虽然业内很多号称毫秒级，一般是省略了数据校验，或者只校验条数。号称是算法精巧已经测试比较充分了。DDM认为即使测试已经充分了也难以保证百分之一百保证不出问题。所以DDM通过设计了快速的校验算法，对数据的内容进行校验，即使数据有一点点不一样，算法也能校验出来，同时充分利用了RDS的计算能力提高校验的速度。 在一般的大型应用里，有的表数据量很大，有的表数据量少且不怎么更新，DDM是如何做到不同类型场景的支持？针对业务会遇到的实际场景，DDM设计了三种表类型：分片表：针对那些数据量很大的表，需要切分到多个分片库的表，这样每个分片都有一部分数据，所有分片构成了完整的数据；单表：针对数据量相对比较少，没有和其他分片表join查询的需求。单表数据保存在默认当一个分片上，这种设计可以尽量兼容单表自身的复杂查询；全局表：针对数据量和更新都比较少，但是和其它分片表有join的需求。全局表每个分片上保存一份完全一样的数据，这样可以解决与分片表的join直接下推到RDS上执行。 在分布式条件下，原有数据库中的主键约束将无法使用，是不是需要引入外部机制保证数据唯一性标识，那么这种全局唯一序列DDM是如何保证的呢？DDM 全局唯一序列，使用方法与 MySQL的AUTO_INCREMENT 类似。目前 DDM 可以保证该字段全局唯一和有序递增，但不保证连续性。目前DDM设计了2种类型的序列机制，DB和TIME。DB方式的序列是指通过DB来实现，需要注意步长的设置，步长直接关系到序列的性能，步长的大小决定了一次批量取序列的大小。TIME序列使用了时间戳加机器编号的生成方式，好处是无需通讯即可保证唯一性。 DDM在运维监控方面的优势？DDM: 采用传统中间件运维完全需要自己运维，一般中间件专注核心功能，较少考虑运维和图形化界面的操作。DDM充分利用云化的优势，提供了对实例、逻辑库、逻辑表、分片算法等的全面图形化界面操作。同时可以在线查看慢SQL等监控内容，方便对系统进行针对性的性能调优。 未来DDM会往什么方向发展？DDM未来方向对分布式事务、分布式查询能力增强、性能的优化等，考虑到有些特性实现如果只从中间件层面实现会限制比较多。DDM会通过与数据库底层的修改进行配合，一起提供更优秀的特性来满足用户的业务需求。

本帖最后由 云彩飞扬 于 2018-3-20 09:52 编辑当 RDS 的 IOPS、CPU、磁盘容量等指标到达瓶颈，并且 SQL 优化、数据分片都已无法解决问题时，可通过水平扩容增加RDS数量，以提升数据库的容量。扩容涉及数据迁移，期间可能会中断业务，这对企业来说是一个很大的挑战。12841关于数据库水平扩容，业界常见的解决办法有如下几个：① 停机迁移：需要中断业务，数据量越大停机时间会越长，对业务影响大，且不支持增量迁移。② 应用双写：应用的数据同时写两份，性能开销大，数据的一致性难以保证。③ 整库迁移：预留分片数，将分片库整体迁移到新的RDS上，这种方案的缺点分片库个数没法扩展，数据也没有做到真正均衡。DDM的平滑扩容数据再均衡技术，是真正意义上的数据重分布。仅需在DDM控制台点击加入新的RDS节点，后台就会如丝般顺滑地自动完成扩容，整个扩容过程业务完全不感知。每个新加入的RDS上都会自动增加新的分片，并把原有表中的部分数据迁移到新节点上，保证最终所有的数据都是均衡分布。越来越多的企业选择把业务迁移上云，而数据库作为大部分企业应用的核心组件，数据的管理和运营成为企业下一阶段成败的关键。业务飞速发展引发的海量并发，海量存储等现象使得传统的数据库方案面临新的困境。DDM提供线性水平扩展、分库分表、读写分离等能力，轻松应对超高并发、海量数据等场景，有效提升数据检索效率，为企业提供更高性价比的数据库解决方案。[table=50%,LightBlue] 单机数据库痛点DDM核心优势容易产生容量与性能瓶颈自动数据分片传统的分区分表或分库方案限制太多透明读写分离单机数据库服务器成本高昂平滑弹性伸缩运维复杂人力成本高无忧运维控制台一键管理

发扬工匠精神，DDM为了给用户提供性能最强的云服务，致力于降低每一个环节上的性能损耗。应用程序连接到DDM的链路上可能会有性能损失，一些企业通过自行研发客户端程序来实现负载均衡，但这样一来，服务部署和升级的复杂度都会大大提升，目前业界并没有通用的成熟的解决方案。针对这一问题，DDM内部实现了MySQL原生通信协议，将自己模拟成一个MySQL客户端，使应用程序连接到DDM和连接到普通的MySQL一样。此外，DDM采用MySQL JDBC驱动自带的负载均衡模型，不仅提供客户端负载均衡，还支持容灾切换，如果集群内部有节点发生故障，驱动会自动屏蔽掉该故障节点，故障恢复后会自动加入到负载均衡。应用程序通过JDBC loadblance连接到DDM，链路畅通无阻，没有中间LB节点带来性能损耗，还提供事务级负载均衡，给用户带来卓越的性能体验。

对于企业而言，无论业务是否上云，服务的稳定性和可靠性都是至关重要的。为了降低不可抗力因素对服务的正常运行造成的影响，需要尽量提高服务的高可用性和容灾能力。12726我们知道云服务各个Region会有多个AZ（Availability Zone)，AZ是指在同一地域内，电力和网络互相独立的物理区域。DDM支持将集群节点分布到多个AZ，有效避免整个AZ机房故障造成的业务中断，从而提升服务的可用性。开拓创新远远不止步于此，DDM的后台架构也采用数据的分片存储的方案，将RDS主备实例分布在多个AZ，只读副本也分布在多个AZ。这样DDM+RDS的整体架构方案都支持跨AZ的高可用，最大限度的保障了服务的可靠性。

你想不想和大神来一次 “亲密”的技术交流吗？你在产品使用中是否遇到了疑惑？你有不吐不快的话想要向技术大咖直接诉说吗？ {:9_88:}机会来啦！在本帖下面回复，有啥说啥，有啥问啥，将会有技术大咖、产品经理为您专业解答！ 活动规则 1.活动时间：2018年3月15日-2018年6月30日； 2.参与方式：第一步：未登录或未注册用户，点击活动页面右上角“登录”或“注册”完成注册或登录；第二步：进入对应产品论坛版块；第三步：在本帖盖楼，直接抛出你的问题，发表问题后，请耐心等待专家进行回复； 3.专家回复时间：工作日8:30-12:00、13:30-18:00，其余时间，等待下个工作日进行回复；

DDM目前支持多种不同规格的实例。核数越多，并行计算能力越强；内存越大，支持更复杂更大批量的数据查询与处理。用户可以根据自己的业务规划选择合适的规格，在满足业务需要的同时降低使用成本。一般说来，数据库以能够支撑业务高峰时期的并发为基本需求。假设以QPS为指标衡量业务需求，在RDS实例不成为性能瓶颈的前提下，4C|8G的DDM实例能支撑QPS高峰在15000以内的业务，8C|16G的DDM实例能支撑QPS高峰在35000以内的业务，16C|32G的DDM实例能支撑QPS高峰在70000以内的业务，32C|64G的DDM实例能支撑QPS高峰在105000以内的业务。说明：实际场景中的QPS支撑能力，受网络、存储、表设计、SQL执行计划、单条数据的大小等多方面的影响，以上QPS指标采用sysbench工具及其OLTP模型测试得到。

企业将RDS中的数据迁移到DDM，可以释放RDS以避免浪费。如果原来的RDS还在DDM中使用的，验证迁移成功之后，删除原来的database以释放空间。如果原来的RDS不再使用，则可以直接删除原来的RDS实例。

本帖最后由 xiangyuehua 于 2018-3-6 17:43 编辑导入数据是指将导出数据导出的文本文件上传到ECS，然后从ECS将文件导入到DDM。操作步骤[*]将数据文件test.dump上传到弹性云服务器。[*]登录弹性云服务器。该弹性云服务器需要与DDM网络连通。[*]用mysql客户端连接DDM，使用source命令将数据文件导入DDM。[code]D:\mysqldump>mysql -h 192.168.0.100 -P5066 -uroot -p ddm_test Enter password: ********** mysql> set autocommit=0; mysql> source D:\mysqldump\test.dump; mysql> commit;[/code] [*]192.168.0.100为待导入数据的DDM的地址。 [*]5066为DDM侦听端口。 [*]root为数据库用户。 [*]ddm_test为数据库名称。 [*]D:\mysqldump\test.dump为导出的存储路径以及文件名。建议检查表中内容，验证导出是否成功。注意： [list=a] [*]为确保数据导入正确，请在客户端或存储过程中设置手动提交事务。客户端设置如上述回显中的命令：set autocommit=0; {sql operations}; commit; [*]数据导入阶段会在一定程度上影响DDM以及RDS实例性能，请选择在业务空闲时间导入。 4.检查迁移是否成功。检查表中的数据与导出之前是否相同执行SELECT COUNT(*)检查每张表的行数在导出之前是否与导入之后相同如果两者都相同，则表示数据迁移成功。

本帖最后由 xiangyuehua 于 2018-3-6 17:34 编辑导出数据是指将数据从原有数据库中导出到一个单独的文本文件中。操作步骤在命令行工具中使用mysqldump将源数据库转储至SQL文件。根据命令提示输入数据库用户密码。C:\Users\mysql>mysqldump --host 192.168.0.100 -P3306 -uroot -p -t -n --complete-insert --databases mysql_db >D:\mysqldump\test.dumpEnter password: **********C:\Users\mysql>1.192.168.0.100为待导出数据的数据库连接地址。2.3306为数据库侦听端口。3.root为数据库用户。4.mysql_db为数据库名称。5.D:\mysqldump\test.dump为导出文件名以及存储路径。6.参数-t表示不导出建表语句。也可以使用--no-create-info。7.参数-n表示不导出建库语句。也可以使用--no-create-db。8.参数--complete-insert表示导出的insert语句包含所有列名称。9.参数--databases表示导出指定的数据库。注意：DDM不支持以自动新建库或者新建表的方式导入数据。因此导入数据前需要先通过DDM管理控制台创建好相同名称的逻辑库，相同表结构的逻辑表，然后再进行数据导入。数据导出命令中需增加忽略DDL语句的参数。命令执行完会生成test.dump文件，如下：D:\mysqldump>dir2017/07/15 10:23 231,123,647 test.dump D:\mysqldump>

本帖最后由 xiangyuehua 于 2018-3-6 17:24 编辑迁移前需要做的准备工作主要包括：[*]申请华为云账号。 [*]创建vpc、子网、安全组，确保RDS、DDM、ECS都在同一个vpc子网下，才能实现网络互通。 [*]申请DDM实例。 [*]申请RDS实例，实例个数和存储空间根据已有业务情况进行估算。查看原有数据量，保证DDM上所有的RDS存储空间之和大于原有数据量。需要连接到数据库，执行如下命令查看数据量：use information_schema;select concat(round(sum(DATA_LENGTH/1024/1024), 2),´MB´)as data from TABLES; [*]准备一个ECS，装好MySQL客户端，MySQL版本建议为5.6及以上。dump文件可以分批上传至ECS，请每次上传时判断ECS剩余磁盘空间。如果ECS空间不足，可以待上传的dump文件导入到DDM后，删除已经导入的dump文件，再上传新的dump文件。ECS的磁盘空间大小可以通过df -h命令查看。 [*]评估应用程序sql语句在DDM中的兼容性。可参考兼容性列表自行评估或联系华为专家评估。 [*]确保已经完成原有数据库的数据表结构的分析，并在DDM中创建对应的逻辑库和逻辑表，创建逻辑库的操作请参见创建逻辑库，创建逻辑表的操作请参见创建逻辑表。 [*]如果是分片表，还需要配置好分片规则和分片字段。 [*]如果是全局表，还需要全局主键的配置好全局序列。 [*]弹性云服务器需要安装好mysql客户端。下载地址见：https://www.mysql.com/downloads/。

本帖最后由 云彩飞扬 于 2018-3-7 16:48 编辑针对不同的业务场景，迁移流程会略有区别，执行迁移操作前，请先确认业务场景。业务场景一企业做应用服务迁移上云，购买了DDM服务后，原有数据需要导入到新的数据库。数据迁移的流程请参见图1 场景一数据迁移流程 此场景下，数据迁移包括如下步骤：[*]迁移前准备 介绍在正式迁移之前需要做的一些准备工作。 [*]导出数据 将数据从数据库中导出到文本文件中。 [*]导入数据 将文本文件上传到ECS，再将文件文件中的数据导入到DDM。 业务场景二企业在华为云上已经购买并使用了RDS，但是没有使用DDM，现在开始使用DDM。此场景下，数据迁移包括如下步骤：[*]迁移前准备 [*]导出数据 [*]导入数据 [*]释放RDS 数据迁移的流程请参见。图2 场景二数据迁移流程