数据迁移

市场需求 产品概述 利用场景 可行性 产品价值 参考资料 [收费下载](https://github.com/hw2499/etl-engine/releases) [etl-engine使用手册](https://github.com/hw2499/etl-engine) [etl-crontab使用手册](https://github.com/hw2499/etl-engine/wiki/etl-crontab%E8%B0%83%E5%BA%A6) [嵌入脚本开发](https://github.com/hw2499/etl-engine/wiki/%E5%B5%8C%E5%85%A5%E8%84%9A%E6%9C%AC%E5%BC%80%E5%8F%91) [etl-engine配置样例](https://github.com/hw2499/etl-engine/wiki/etl-engine%E4%BD%BF%E7%94%A8%E6%A0%B7%E4%BE%8B)文章起源https://pan.baidu.com/s/1eMkM85RPqI76VaJVReVDJQ?pwd=k4dy

作者：高鹏 DBA，负责我的项目日常问题排查，广告位长期出租 。 本文起源：原创投稿 *爱可生开源社区出品，原创内容未经受权不得随便应用，转载请分割小编并注明起源。 本文次要贡献者：进行OMS源码剖析的@操盛春（北分之光） 一、走进OMS本文以OMS社区版3.3.1为例 咱们能够从官网的地址上获取到它的架构图，这是它大略的样子： 能够看到一个OMS数据迁徙工具它蕴含了很多的组件，有DBCat、Store、Connector、JDBCWriter、Checker 和 Supervisor 等，组件的各个性能这里就不copy官网的叙述了，毕竟有手就行。接下来说点官网上没有的。 之前领导让我进行OMS性能测试时要顺便打印火焰图看一下，剖析迁徙过程中工夫都用在了哪里，然而当我登录OMS容器后看到很多相干java过程，一时间分不清哪个过程是做什么的，那么接下里咱们就对这些过程逐个阐明 1.Ghana-endpoint[ActionTech ~]# ps uax | grep Ghana-endpointroot 61 3.1 0.5 20918816 1582384 pts/0 Sl Feb07 1756:47 java -Dspring.config.location=/home/ds/ghana/config/application-oms.properties -server -Xms1g -Xmx2g -XX:+PrintGCDetails -XX:+PrintGCTimeStamps -XX:+PrintGCDateStamps -Xloggc:/home/admin/logs/ghana/gc.log -XX:+UseGCLogFileRotation -XX:NumberOfGCLogFiles=10 -XX:GCLogFileSize=10M -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/home/admin/logs/ghana -jar /home/ds/ghana/boot/Ghana-endpoint-1.0.0-executable.jarGhana-endpoint负责提供OMS 后盾治理界面、调度TaskJob和StructTaskJob程序 tips: StructTaskJob：构造迁徙任务调度程序 TaskJob： TaskJob::scheduledTask()，负责正向切换步骤的子工作执行的调度TaskJob::scheduleMigrationProject()，负责构造迁徙我的项目所有步骤初始化 & 工作执行进度监控的调度2.commons-daemon（CM）[ActionTech ~]# ps uax | grep commons-daemonroot 50 297 1.7 25997476 4711620 pts/0 Sl Feb07 163685:09 java -cp /home/ds/cm/package/deployapp/lib/commons-daemon.jar:/home/ds/cm/package/jetty/start.jar -server -Xmx4g -Xms4g -Xmn4g -Dorg.eclipse.jetty.util.URI.charset=utf-8 -Dorg.eclipse.jetty.server.Request.maxFormContentSize=0 -Dorg.eclipse.jetty.server.Request.maxFormKeys=20000 -DSTOP.PORT=8089 -DSTOP.KEY=cm -Djetty.base=/home/ds/cm/package/deployapp org.eclipse.jetty.start.MainCM集群治理过程，为OMS 治理后盾过程提供接口，用于创立拉取增量日志、全量迁徙、增量同步、全量校验等工作，以及获取这些工作的执行进度 ...

互联网诞生之初尽管数据量暴增，单日事实表条数达千万级别， 但客户需要场景更多是“t+1”模式，只需对当日、当周、当月数据进行剖析，这些诉求仅离线剖析就可满足。 随着大数据畛域一直倒退，企业对于业务场景的诉求也从离线的满足转到高实时性的要求，数栈产品也在这一过程中进行着一直的迭代降级，随之诞生了kafka+flink组合 ，同时kafka + etl-engine（交融计算的加持）组合也实现了轻量级的流式计算引擎。 流计算与批计算比照数据时效性流式计算实时、低提早，流式计算适宜以“t+0”的模式出现业务数据；批计算非实时、高提早，批计算适宜以“t+1”的模式出现业务数据；数据特色流式计算数据个别是动态数据，数据是随时产生的；批计算数据个别是静态数据，数据当时曾经存储在各种介质中。利用场景流式计算利用在实时场景，如：业务监控、实时举荐等。批计算利用在离线计算场景，如：数据分析、离线报表等。运行形式流式计算的工作是阻塞式的，始终继续运行中。批计算的工作是一次性实现即完结。 etl-engine 实现流式计算etl-engine 反对通过本身提供的 ”kafka生产节点“进行音讯生产，并在生产数据流（音讯流）的同时调用本身提供的“交融查问API”，实现将多种数据源的维表数据读取到内存中，而后将音讯流与多个维表数据进行各种关联查问，最初输入交融查问后果集到指标源，罕用在将多个维表数据与实时音讯流关联后转换成一个大宽表的场景。 交融查问语法交融查问语法遵循ANSI SQL规范，与惯例MySQL查问语法很类似。 反对对多种类别数据库之间读取的数据进行交融查问。反对音讯流数据传输过程中动静产生的数据与多种类型数据库之间的流计算查问。交融查问语法遵循ANSI SQL规范。select 反对SELECT [DISTINCT] field [, field ...] FROM table [, table ...] [WHERE condition] [GROUP BY field [, field ...] ] [HAVING condition] [ORDER BY order_item [, order_item ...] ] [LIMIT number_of_records [OFFSET number_of_records ] ]table 反对 INNER JOINLEFT JOINRIGHT JOINOUTER JOINCROSS JOIN后续会具体介绍交融查问反对的内容。 参考资料 [收费下载](https://github.com/hw2499/etl-engine/releases) [etl-engine使用手册](https://github.com/hw2499/etl-engine) [etl-crontab使用手册](https://github.com/hw2499/etl-engine/wiki/etl-crontab%E8%B0%83%E5%BA%A6) [嵌入脚本开发](https://github.com/hw2499/etl-engine/wiki/%E5%B5%8C%E5%85%A5%E8%84%9A%E6%9C%AC%E5%BC%80%E5%8F%91) [etl-engine配置样例](https://github.com/hw2499/etl-engine/wiki/etl-engine%E4%BD%BF%E7%94%A8%E6%A0%B7%E4%BE%8B)

作者：沈光宇 爱可生南区 DBA 团队成员，次要负责 MySQL 故障解决和性能优化。对技术执着，为客户负责。 本文起源：原创投稿 *爱可生开源社区出品，原创内容未经受权不得随便应用，转载请分割小编并注明起源。 一、背景某客户MySQL实例中数据较大(上T的数据量)，须要将MySQL中数据全量/增量疾速迁徙至DBLE。TiDB DM反对多线程数据导出导入及增量同步，因而抉择了TiDB DM为作数据迁徙工具。本文以此案例为背景，介绍应用TiDB DM将数据从MySQL迁徙至DBLE的办法及遇到的一些问题。 二、数据迁徙示意图及服务器环境（1）数据迁徙示意图如下： （2）服务器环境如下:服务器IP角色端口版本备注10.186.65.83dm master8261/8291V2.0.7tiup装置节点10.186.65.118dm worker8262V2.0.7 10.186.65.14SRC MySQL4490MySQL 8.0.18 10.186.65.4DBLE8066DBLE 3.21.10.6 10.186.65.61DBLE datanode4408MySQL 8.0.25 10.186.65.65DBLE datanode4408MySQL 8.0.25 三、装置 TiDB DM（1）筹备环境及装置 tiup#别离在dm master和worker节点主机创立tidb用户,明码为dmadmin,并配置sudoshell> useradd tidbshell> echo "dmadmin" | passwd tidb --stdinshell> echo "tidb ALL=(ALL) NOPASSWD: ALL" > /etc/sudoers.d/tidb#切换至tidb用户,生成密钥，并做ssh信赖,dm集群内机器都须要做ssh信赖shell> su - tidbshell> ssh-keygen -t rsashell> ssh-copy-id -i ~/.ssh/id_rsa.pub tidb@10.186.65.118shell> ssh-copy-id -i ~/.ssh/id_rsa.pub tidb@10.186.65.83#装置tiup,在tidb用户下shell> curl --proto '=https' --tlsv1.2 -sSf https://tiup-mirrors.pingcap.com/install.sh | shshell> source .bash_profileshell> which tiup~/.tiup/bin/tiup#装置dmctlshell> tiup install dm dmctl:v2.0.7component dm version v1.10.2 is already installeddownload https://tiup-mirrors.pingcap.com/dmctl-v2.0.7-linux-amd64.tar.gz 26.92 MiB / 26.92 MiB 100.00% 10.01 MiB/s（2）装置dm-cluster#生成配置模版shell> tiup dm template > dm_topology.yaml#批改后配置文件如下：shell> cat dm_topology.yaml |grep -v ^[#-] |grep -v ^$global: user: "tidb" ssh_port: 22 deploy_dir: "/home/tidb/dm/deploy" data_dir: "/home/tidb/dm/data"master_servers: - host: 10.186.65.83worker_servers: - host: 10.186.65.118monitoring_servers: - host: 10.186.65.83grafana_servers: - host: 10.186.65.83alertmanager_servers: - host: 10.186.65.83 #装置、并启动DM集群shell> tiup dm deploy dm-test v2.0.7 ./dm_topology.yaml --user tidb -i /home/tidb/.ssh/id_rsashell> tiup dm start dm-test#查看DM集群[tidb@10_186_65_83 ~]$ tiup dm display dm-testtiup is checking updates for component dm ...Starting component `dm`: /home/tidb/.tiup/components/dm/v1.10.2/tiup-dm display dm-testCluster type: dmCluster name: dm-testCluster version: v2.0.7Deploy user: tidbSSH type: builtinGrafana URL: http://10.186.65.83:3000ID Role Host Ports OS/Arch Status Data Dir Deploy Dir-- ---- ---- ----- ------- ------ -------- ----------10.186.65.83:9093 alertmanager 10.186.65.83 9093/9094 linux/x86_64 Up /home/tidb/dm/data/alertmanager-9093 /home/tidb/dm/deploy/alertmanager-909310.186.65.83:8261 dm-master 10.186.65.83 8261/8291 linux/x86_64 Healthy|L /home/tidb/dm/data/dm-master-8261 /home/tidb/dm/deploy/dm-master-826110.186.65.118:8262 dm-worker 10.186.65.118 8262 linux/x86_64 Free /home/tidb/dm/data/dm-worker-8262 /home/tidb/dm/deploy/dm-worker-826210.186.65.83:3000 grafana 10.186.65.83 3000 linux/x86_64 Up - /home/tidb/dm/deploy/grafana-300010.186.65.83:9090 prometheus 10.186.65.83 9090 linux/x86_64 Up /home/tidb/dm/data/prometheus-9090 /home/tidb/dm/deploy/prometheus-9090Total nodes: 5四、DBLE端配置（1）db.xml<?xml version="1.0"?><dble:db xmlns:dble="http://dble.cloud/"> <dbGroup name="dbGroup1" rwSplitMode="0" delayThreshold="-1"> <heartbeat>select 1</heartbeat> <dbInstance name="host_1" url="10.186.65.61:4408" user="sgy" password="QfnHoIeIYL7ZT+EdJMYNuiLw6glbx2hEyrqxK+uxFPU8vja8vZHCLEKvKBOt1vOJdXCCgW7wNidJaTYWORDaUg==" maxCon="2000" minCon="50" primary="true" usingDecrypt="true"></dbInstance> </dbGroup> <dbGroup name="dbGroup2" rwSplitMode="0" delayThreshold="-1"> <heartbeat>select 1</heartbeat> <dbInstance name="host_2" url="10.186.65.65:4408" user="sgy" password="d+rG/82+4h21ARS8D6Gu5MIFQ2UBC0h+ZS0EI7bvWAtTJUBsKuFY8+AVZtW1pZk+qtISoI2WpVt29Z9eqMRP5A==" maxCon="2000" minCon="50" primary="true" usingDecrypt="true"></dbInstance> </dbGroup></dble:db>#注：用户明码为加密后的字符串（2）sharding.xml<?xml version="1.0"?><dble:sharding xmlns:dble="http://dble.cloud/" > <schema name="dm_meta" sqlMaxLimit="-1"> <singleTable name="mysql_sync_to_dble_loader_checkpoint" shardingNode="dm_meta" /> <singleTable name="mysql_sync_to_dble_syncer_checkpoint" shardingNode="dm_meta" /> </schema> <schema name="sbtest" sqlMaxLimit="-1"> <shardingTable name="sbtest1" shardingNode="dn1,dn2,dn3,dn4" sqlMaxLimit="-1" shardingColumn="id" function="pro_func_jumpHash"></shardingTable> <shardingTable name="sbtest2" shardingNode="dn1,dn2,dn3,dn4" sqlMaxLimit="-1" shardingColumn="id" function="pro_func_jumpHash"></shardingTable> <shardingTable name="t1" shardingNode="dn1,dn2,dn3,dn4" sqlMaxLimit="-1" shardingColumn="c1" function="pro_func_jumpHash"></shardingTable> <shardingTable name="t2" shardingNode="dn1,dn2,dn3,dn4" sqlMaxLimit="-1" shardingColumn="c1" function="pro_func_jumpHash"></shardingTable> </schema> <shardingNode name="dn1" dbGroup="dbGroup1" database="dh_dn1"></shardingNode> <shardingNode name="dn2" dbGroup="dbGroup1" database="dh_dn2"></shardingNode> <shardingNode name="dn3" dbGroup="dbGroup2" database="dh_dn3"></shardingNode> <shardingNode name="dn4" dbGroup="dbGroup2" database="dh_dn4"></shardingNode> <shardingNode name="dm_meta" dbGroup="dbGroup1" database="dm_meta"/> <function name="pro_func_jumpHash" class="jumpStringHash"> <property name="partitionCount">4</property> <property name="hashSlice">0:0</property> </function></dble:sharding>注：须要提前配置好DM同步时保留数据的schema及两张表,表名别离是dm同步工作名 + _loader_checkpoint 即表mysql_sync_to_dble_loader_checkpointdm同步工作名 + _syncer_checkpoint 即表mysql_sync_to_dble_syncer_checkpoint（3）user.xml<?xml version="1.0"?><dble:user xmlns:dble="http://dble.cloud/"> <managerUser name="root" password="RYQdYYnzbcZlDuhV4LhJxFTM8kbU3d0y183LU+FgRWzNscvvvFPcdmeEKMdswMyzIaA+kObcozliHEYAlT0AjA==" usingDecrypt="true"></managerUser> <shardingUser name="sz" schemas="sbtest,dm_meta" password="jyaXmGFU+mdTGbUZIVbdEcVwItLPI+Yjxdq4wkOzhAYRB29WGZJd0/PkTJh3ky/v4E2yYoqgUzJXPzPRPiQF0Q==" usingDecrypt="true" readOnly="false" maxCon="1000"></shardingUser></dble:user>#注：用户明码为加密后的字符串（4）登陆 DBLE 治理端执行创立物理数据库命令shell> /data/mysql/base/5.7.36/bin/mysql -uroot -padmin -h 10.186.65.4 -P 9066dble> create database @@shardingNode = 'dn$1-4';Query OK, 1 row affected (0.06 sec)dble> create database @@shardingNode = 'dm_meta';Query OK, 1 row affected (0.01 sec)五、在源端 MySQL 压测创立测试数据#执行prepare，初始化100W行数据 /usr/share/sysbench/oltp_insert.lua --mysql-db=sbtest --mysql-host=10.186.65.14 --mysql-port=4490 --mysql-user=sgy --mysql-password=admin --tables=2 --table-size=1000000 --threads=16 --time=60 --report-interval=1 --max-requests=0 --percentile=95 --mysql-ignore-errors=1062 preparesysbench 1.0.17 (using system LuaJIT 2.0.4)Initializing worker threads...Creating table 'sbtest1'...Creating table 'sbtest2'...Inserting 1000000 records into 'sbtest2'Inserting 1000000 records into 'sbtest1'Creating a secondary index on 'sbtest2'...Creating a secondary index on 'sbtest1'...#利用sysbench一直写入数据shell> /usr/share/sysbench/oltp_read_write.lua --mysql-db=sbtest --mysql-host=10.186.65.14 --mysql-port=4490 --mysql-user=sgy --mysql-password=admin --tables=2 --table-size=2000000 --threads=16 --time=6000 --report-interval=1 --max-requests=0 --percentile=95 --mysql-ignore-errors=1062 runsysbench 1.0.17 (using system LuaJIT 2.0.4)Running the test with following options:Number of threads: 16Report intermediate results every 1 second(s)Initializing random number generator from current timeInitializing worker threads...Threads started![ 1s ] thds: 16 tps: 585.44 qps: 11916.49 (r/w/o: 8360.33/1282.63/2273.53) lat (ms,95%): 55.82 err/s: 0.00 reconn/s: 0.00[ 2s ] thds: 16 tps: 744.18 qps: 14819.02 (r/w/o: 10379.16/1609.36/2830.50) lat (ms,95%): 41.85 err/s: 0.00 reconn/s: 0.00[ 3s ] thds: 16 tps: 605.11 qps: 12144.20 (r/w/o: 8500.54/1321.24/2322.42) lat (ms,95%): 47.47 err/s: 0.00 reconn/s: 0.00[ 4s ] thds: 16 tps: 773.91 qps: 15558.16 (r/w/o: 10881.71/1737.79/2938.65) lat (ms,95%): 41.10 err/s: 0.00 reconn/s: 0.00六、启动数据同步工作（1）配置数据源#应用dmctl工具生成明码加密字符串,每次执行都会产生不同的加密字符串shell> tiup dmctl encrypt 'admin'dmXgktpuF18RP1mDN/B2UkA6pDN9PQ==#mysql数据库配置文件如下shell> cat mysql_source_14_4490.yamlsource-id: "mysql_source_14_4490"from: host: "10.186.65.14" port: 4490 user: "sgy" password: "dmXgktpuF18RP1mDN/B2UkA6pDN9PQ==" #创立数据源shell> tiup dmctl --master-addr 10.186.65.83:8261 operate-source create ./mysql_source_14_4490.yamlStarting component `dmctl`: /home/tidb/.tiup/components/dmctl/v2.0.7/dmctl/dmctl --master-addr 10.186.65.83:8261 operate-source create ./mysql_source_14_4490.yaml{ "result": true, "msg": "", "sources": [ { "result": true, "msg": "", "source": "mysql_source_14_4490", "worker": "dm-10.186.65.118-8262" } ]}#查看数据源shell> tiup dmctl --master-addr 10.186.65.83:8261 operate-source show{ "result": true, "msg": "", "sources": [ { "result": true, "msg": "", "source": "mysql_source_14_4490", "worker": "dm-10.186.65.118-8262" } ]}（2）配置同步工作#同步配置文件如下shell> cat mysql_sync_to_dble.yamlname: "mysql_sync_to_dble" #同步工作名task-mode: "all" #全量 + Binlog 实时同步clean-dump-file: truetimezone: "Asia/Shanghai"ignore-checking-items: ["auto_increment_ID"]target-database: host: "10.186.65.4" #DBLE主机IP地址 port: 8066 #DBLE流量端口 user: "sz" #连贯DBLE的用户 password: "KRfSNtdxe63tehpnCYoCz0ABdUGivg==" #连贯DBLE用户明码，用tiup dmctl encrypt 'password'生成mysql-instances:- source-id: "mysql_source_14_4490" block-allow-list: "global" mydumper-config-name: "global" loader-config-name: "global" syncer-config-name: "global"block-allow-list: global: do-dbs: ["sbtest"] #只迁徙sbtest库mydumpers: global: extra-args: "-B sbtest" #只dump sbtest库loaders: global: pool-size: 8syncers: global: worker-count: 8#更具体配置阐明参考官网文档：https://docs.pingcap.com/zh/tidb-data-migration/v2.0/task-configuration-file-full#%E5%AE%8C%E6%95%B4%E9%85%8D%E7%BD%AE%E6%96%87%E4%BB%B6%E7%A4%BA%E4%BE%8B#查看配置文件shell> tiup dmctl:v2.0.7 --master-addr=10.186.65.83:8261 check-task ./mysql_sync_to_dble.yamlStarting component `dmctl`: /home/tidb/.tiup/components/dmctl/v2.0.7/dmctl/dmctl --master-addr=10.186.65.83:8261 check-task ./mysql_sync_to_dble.yaml{ "result": true, "msg": "check pass!!!"}#启动同步工作shell> tiup dmctl:v2.0.7 --master-addr=10.186.65.83:8261 start-task ./mysql_sync_to_dble.yamlStarting component `dmctl`: /home/tidb/.tiup/components/dmctl/v2.0.7/dmctl/dmctl --master-addr=10.186.65.83:8261 start-task ./mysql_sync_to_dble.yaml{ "result": true, "msg": "", "sources": [ { "result": true, "msg": "", "source": "mysql_source_14_4490", "worker": "dm-10.186.65.118-8262" } ]}#在dm-worker节点查看导出的SQL文件, shell> ls -lh /home/tidb/dm/deploy/dm-worker-8262/dumped_data.mysql_sync_to_dbletotal 384M-rw-r--r-- 1 tidb tidb 187 Aug 5 14:04 metadata-rw-r--r-- 1 tidb tidb 48M Aug 5 14:04 sbtest.sbtest1.0000000000000.sql-rw-r--r-- 1 tidb tidb 48M Aug 5 14:04 sbtest.sbtest1.0000000010000.sql-rw-r--r-- 1 tidb tidb 48M Aug 5 14:04 sbtest.sbtest1.0000000020000.sql-rw-r--r-- 1 tidb tidb 48M Aug 5 14:04 sbtest.sbtest1.0000000030000.sql-rw-r--r-- 1 tidb tidb 369 Aug 5 14:04 sbtest.sbtest1-schema.sql-rw-r--r-- 1 tidb tidb 48M Aug 5 14:04 sbtest.sbtest2.0000000000000.sql-rw-r--r-- 1 tidb tidb 48M Aug 5 14:04 sbtest.sbtest2.0000000010000.sql-rw-r--r-- 1 tidb tidb 48M Aug 5 14:04 sbtest.sbtest2.0000000020000.sql-rw-r--r-- 1 tidb tidb 48M Aug 5 14:04 sbtest.sbtest2.0000000030000.sql-rw-r--r-- 1 tidb tidb 369 Aug 5 14:04 sbtest.sbtest2-schema.sql-rw-r--r-- 1 tidb tidb 152 Aug 5 14:04 sbtest-schema-create.sql#创立库SQL文件shell> head /home/tidb/dm/deploy/dm-worker-8262/dumped_data.mysql_sync_to_dble/sbtest-schema-create.sql/*!40101 SET NAMES binary*/;CREATE DATABASE `sbtest` /*!40100 DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_bin */ /*!80016 DEFAULT ENCRYPTION='N' */;#创立表SQL文件shell> head /home/tidb/dm/deploy/dm-worker-8262/dumped_data.mysql_sync_to_dble/sbtest.sbtest1-schema.sql/*!40101 SET NAMES binary*/;CREATE TABLE `sbtest1` ( `id` int(11) NOT NULL AUTO_INCREMENT, `k` int(11) NOT NULL DEFAULT '0', `c` char(120) COLLATE utf8mb4_bin NOT NULL DEFAULT '', `pad` char(60) COLLATE utf8mb4_bin NOT NULL DEFAULT '', PRIMARY KEY (`id`), KEY `k_1` (`k`)) ENGINE=InnoDB AUTO_INCREMENT=1000001 DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_bin;#dump生成批量插入数据SQL文件shell> head /home/tidb/dm/deploy/dm-worker-8262/dumped_data.mysql_sync_to_dble/sbtest.sbtest1.0000000000000.sql/*!40101 SET NAMES binary*/;INSERT INTO `sbtest1` (`id`,`k`,`c`,`pad`) VALUES(1,498670,'31451373586-15688153734-79729593694-96509299839-83724898275-86711833539-78981337422-35049690573-51724173961-87474696253','98996621624-36689827414-04092488557-09587706818-65008859162'),(2,497778,'21472970079-70972780322-70018558993-71769650003-09270326047-32417012031-10768856803-14235120402-93989080412-18690312264','04776826683-45880822084-77922711547-29057964468-76514263618'),(3,498956,'49376827441-24903985029-56844662308-79012577859-40518387141-60588419212-24399130405-42612257832-29494881732-71506024440','26843035807-96849339132-53943793991-69741192222-48634174017'),(4,518727,'85762858421-36258200885-10758669419-44272723583-12529521893-95630803635-53907705724-07005352902-43001596772-53048338959','37979424284-37912826784-31868864947-42903702727-96097885121'),(5,502480,'24805466175-85245528617-94635882649-46305216925-28637832581-03224489581-68883711727-95491561683-91969681472-12022277774','19288959552-55556468076-14192290426-55457672510-18043372364'),(6,500774,'52892836230-54177743992-01821871718-48412537487-30066596248-87215430797-00375777469-64498831720-58542556455-90784765418','59487960480-08453890592-99628797439-16757639138-29377916560'),(7,501466,'85820931248-14475640036-11980694501-86588543167-31029306229-09626867980-90685354565-02350460358-25863585366-53793794448','26081374730-86321700986-51212137094-30635959762-03880194434'),(8,497838,'81578049255-33453976301-67096870761-27658738403-30546242249-53677469854-26594573136-34292002037-52736825353-99165193170','64289062455-51067794311-09919261228-11533354367-07401173317'),（3）查看同步工作状态shell> tiup dmctl:v2.0.7 --master-addr=10.186.65.83:8261 query-status ./mysql_sync_to_dble.yamlStarting component `dmctl`: /home/tidb/.tiup/components/dmctl/v2.0.7/dmctl/dmctl --master-addr=10.186.65.83:8261 query-status ./mysql_sync_to_dble.yaml{ "result": true, "msg": "", "sources": [ { "result": true, "msg": "", "sourceStatus": { "source": "mysql_source_14_4490", "worker": "dm-10.186.65.118-8262", "result": null, "relayStatus": null }, "subTaskStatus": [ { "name": "mysql_sync_to_dble", "stage": "Running", "unit": "Sync", "result": null, "unresolvedDDLLockID": "", "sync": { "totalEvents": "425355", "totalTps": "1203", "recentTps": "2386", "masterBinlog": "(mysql-bin.000027, 76114275)", "masterBinlogGtid": "c7827165-bf89-11ec-92e6-02000aba410e:1-5091258", "syncerBinlog": "(mysql-bin.000026, 229462770)", "syncerBinlogGtid": "", "blockingDDLs": [ ], "unresolvedGroups": [ ], "synced": false, "binlogType": "remote", "secondsBehindMaster": "38" } } ] } ]}七、验证数据#暂停先前执行的sysbench程序，确保dm同步与源端无提早时，对表作count(*)#在源端MySQL，对表进行count(*)mysql> select count(*) from sbtest.sbtest1;+----------+| count(*) |+----------+| 1116471 |+----------+1 row in set (0.68 sec)mysql> select count(*) from sbtest.sbtest2;+----------+| count(*) |+----------+| 1117020 |+----------+1 row in set (0.54 sec)#通过dble对表进行count(*)dble> select count(*) from sbtest.sbtest1;+----------+| count(*) |+----------+| 1116471 |+----------+1 row in set (1.04 sec)dble> select count(*) from sbtest.sbtest2;+----------+| count(*) |+----------+| 1117020 |+----------+1 row in set (1.58 sec)#在源端数据进行更新操作mysql> update sbtest.sbtest1 set c=uuid() where id=20;Query OK, 1 row affected (0.01 sec)Rows matched: 1 Changed: 1 Warnings: 0mysql> select * from sbtest.sbtest1 where id=20;+----+--------+--------------------------------------+-------------------------------------------------------------+| id | k | c | pad |+----+--------+--------------------------------------+-------------------------------------------------------------+| 20 | 501448 | 24649f0f-14d1-11ed-b4f2-02000aba410e | 91052688950-96415657187-00012408429-12357288330-41295735957 |+----+--------+--------------------------------------+-------------------------------------------------------------+1 row in set (0.00 sec)#通过dble查问数据dble> select * from sbtest.sbtest1 where id=20;+----+--------+--------------------------------------+-------------------------------------------------------------+| id | k | c | pad |+----+--------+--------------------------------------+-------------------------------------------------------------+| 20 | 501448 | 24649f0f-14d1-11ed-b4f2-02000aba410e | 91052688950-96415657187-00012408429-12357288330-41295735957 |+----+--------+--------------------------------------+-------------------------------------------------------------+1 row in set (0.01 sec)八、注意事项（1）TiDB DM版本要求：TiDB DM v2.0.7（2）在进行数据量导入时须要敞开DBLE慢查问日志#因为数据同步在全量导入阶段会产生大量慢查问，须要在执行同步工作之前先敞开DBLE的慢查问日志shell> mysql --prompt='dble>' -uroot -p -h 10.186.65.4 -P 9066#查看慢查问日志状态，1示意开启，0示意敞开dble> show @@slow_query_log; +------------------+| @@slow_query_log |+------------------+| 1 |+------------------+1 row in set (0.00 sec) #全量数据导入前，敞开dble慢查问日志dble> disable @@slow_query_log;Query OK, 1 row affected (0.01 sec)disable slow_query_log success #待全量数据导入实现后，开启dble慢查问日志dble> enable @@slow_query_log;Query OK, 1 row affected (0.01 sec)enable slow_query_log success（3）查看源端 MySQL 实例上是否有运行相似 pt-kill 的程序#如果在源端MySQL实例上运行有pt-kill或相似的程序，DM同步工作在执行全量数据dump阶段，导出线程可能会被程序kill掉，导致全备失败。dm-worker.log日志如下：[ERROR] [subtask.go:311] ["unit process error"] [subtask=oms-sync-receiver] [unit=Dump] ["error information"="{\"ErrCode\":32001,\"ErrClass\":\"dump-unit\",\"ErrScope\":\"internal\",\"ErrLevel\":\"high\",\"Message\":\"mydumper/dumpling runs with error, with output (may empty): \",\"RawCause\":\"invalid connection\"}"]解决办法：先将pt-kill实用工具进行，而后再从新运行TiDM同步工作，待全量数据dump实现后在开启pt-kill。（4）迁徙时如需对指标表表构造进行批改，如源表有建设分区而指标表通过分片后不须要建设分区、批改表字符集(倡议应用utf8mb4)等，可先将表构造从源库导出，批改后导入 DBLE 或导入 DBLE 后在批改表构造，最初再开启 DM 同步工作。（5）源、指标表字段程序必须要统一，否则可能会导致数据不统一，两字段同为 varchar 并且长度不相等时，同步工作并不会报错，但写入指标表的值可能会被截断，如下图： ...

简介：DataWorks迁徙助手提供工作搬站性能，反对将开源调度引擎Oozie、Azkaban、Airflow的工作疾速迁徙至DataWorks。本文次要介绍如何将开源Azkaban工作流调度引擎中的作业迁徙至DataWorks上。 DataWorks迁徙助手提供工作搬站性能，反对将开源调度引擎Oozie、Azkaban、Airflow的工作疾速迁徙至DataWorks。本文次要介绍如何将开源Azkaban工作流调度引擎中的作业迁徙至DataWorks上。 反对迁徙的Azkaban版本 反对全副版本的Azkaban迁徙。 整体迁徙流程 迁徙助手反对开源工作流调度引擎到DataWorks体系的大数据开发工作迁徙的根本流程如下图所示。 针对不同的开源调度引擎，DataWorks迁徙助手会出一个相干的工作导出计划。整体迁徙流程为：通过迁徙助手调度引擎作业导出能力，将开源调度引擎中的作业导出；再将作业导出包上传至迁徙助手中，通过工作类型映射，将映射后的作业导入至DataWorks中。作业导入时可设置将工作转换为MaxCompute类型作业、EMR类型作业、CDH类型作业等。 Azkaban作业导出 Azkaban工具自身具备导出工作流的能力，有本人的Web控制台，如下图所示： 操作步骤：1.进入Project页面2.点击Flows，会列出Project上面所有的工作流(Flow)3.点击Download即可下载Project的导出文件Azkaban导出包格局原生Azkaban即可，导出包Zip文件外部为Azakaban的某个Project的所有工作(Job)和关系信息。 Azkaban作业导入 拿到了开源调度引擎的导出工作包后，用户能够拿这个zip包到迁徙助手的迁徙助手->工作上云->调度引擎作业导入页面上传导入包进行包剖析。 导入包剖析胜利后点击确认，进入导入工作设置页面，页面中会展现剖析进去的调度工作信息。 开源调度导入设置 用户能够点击高级设置，设置Azkaban工作与DataWorks工作的转换关系。不同的开源调度引擎，在高级设置外面的设置界面基本一致，如下图： 高级设置项介绍： • sparkt-submit转换为：导入过程会去剖析用户的工作是不是sparkt-submit工作，如果是的话，会将spark-submit工作转换为对应的DataWorks工作类型，比如说：ODPS_SPARK/EMR_SPARK/CDH_SPARK等 • 命令行 SQL工作转换为：开源引擎很多工作类型是命令行运行SQL，比如说hive -e, beeline -e, impala-shell等等，迁徙助手会依据用户抉择的指标类型做对应的转换。比方能够转换成ODPS_SQL, EMR_HIVE, EMR_IMPALA, EMR_PRESTO, CDH_HIVE, CDH_PRESTO, CDH_IMPALA等等 • 指标计算引擎类型：这个次要是影响的是Sqoop同步的目标端的数据写入配置。咱们会默认将sqoop命令转换为数据集成工作。计算引擎类型决定了数据集成工作的目标端数据源应用哪个计算引擎的project。 • Shell类型转换为：SHELL类型的节点在Dataworks依据不同计算引擎会有很多种，比方EMR_SHELL，CDH_SHELL，DataWorks本人的Shell节点等等。 • 未知工作转换为：对目前迁徙助手无奈解决的工作，咱们默认用一个工作类型去对应，用户能够抉择SHELL或者虚节点VIRTUAL • SQL节点转换为：DataWorks上的SQL节点类型也因为绑定的计算引擎的不同也有很多种。比方 EMR_HIVE，EMR_IMPALA、EMR_PRESTO，CDH_HIVE，CDH_IMPALA，CDH_PRESTO，ODPS_SQL，EMR_SPARK_SQL，CDH_SPARK_SQL等，用户能够抉择转换为哪种工作类型。 留神：这些导入映射的转换值是动态变化的，和以后我的项目空间绑定的计算引擎无关，转换关系如下。 导入至DataWorks + MaxCompute 导入至DataWorks + EMR 导入至DataWorks + CDH 执行导入 设置完映射关系后，点击开始导入即可。导入实现后，请进入数据开发中查看导入后果。 数据迁徙 大数据集群上的数据迁徙，可参考：DataWorks数据集成或MMA。原文链接本文为阿里云原创内容，未经容许不得转载。

DataX 是阿里巴巴集团内被广泛使用的离线数据同步工具/平台，实现各种异构数据源之间高效的数据同步功能。最近，阿里云cassandra团队为datax提供了cassandra读写插件，进一步丰富了datax支持的数据源，可以很方便实现cassandra之间以及cassandra与其他数据源之间的数据同步。本文简单介绍如何使用datax同步cassandra的数据，针对几种常见的场景给出配置文件示例，还提供了提升同步性能的建议和实测的性能数据。 datax快速入门使用datax同步数据的方法很简单，一共只需要三步： 部署datax。编写同步作业配置文件。运行datax，等待同步作业完成。datax的部署和运行都很简单，可以通过datax官方提供的下载地址下载DataX工具包，下载后解压至本地某个目录，进入bin目录，即可运行同步作业： $ cd {YOUR_DATAX_HOME}/bin$ python datax.py {YOUR_JOB.json}同步作业的配置格式可以参考datax文档。 一个典型的配置文件如下： { "job": { "content": [ { "reader": { "name": "streamreader", "parameter": { "sliceRecordCount": 10, "column": [ { "type": "long", "value": "10" }, { "type": "string", "value": "hello，你好，世界-DataX" } ] } }, "writer": { "name": "streamwriter", "parameter": { "encoding": "UTF-8", "print": true } } } ], "setting": { "speed": { "channel": 5 } } }}一个同步作业的配置文件主要包括两部分，setting包括任务调度的一些配置，content描述同步任务的内容，里面包含reader插件的配置和writer插件的配置。例如我们需要从mysql同步数据到cassandra，那么我们只需要把reader配置为mysqlreader，writer配置为cassandrawriter，并提供相应的插件配置信息即可。在datax项目页面上面可以看到datax支持的插件列表，点击对应的链接就可以查看相关插件的文档了解插件需要的配置内容和格式要求。例如，cassandra插件的文档可点击如下链接：读插件 写插件。 以下列举几种常见的场景。 ...

云原生的时代已经到来，云原生技术正在重塑整个软件生命周期，阿里巴巴是国内最早布局云原生技术的公司之一。 容器服务团队在过去的几年时间内帮助很多用户成功把业务云原生化并迁移上云，其中有现在已经是我们TOP10的大客户，也有需要在国内开展业务的海外用户，有些是从其他云厂商迁移过来的用户，有些是从IDC里迁移上云的用户，而且越来越多的用户开始咨询如何对自己的应用做云原生化改造、如何把业务平滑地迁移到云上。每个用户的业务场景都是不同的，有些差异化的业务场景对容器平台也有一些定制化的需求，我们在帮助这些用户落实迁云方案的同时也在不断思考如何把这些案例中共性的东西做一些沉淀，总结出一些优秀的解决方案、最佳实践以及开发一些工具来帮助用户快速完成迁云的这件事情。这些解决方案、最佳实践以及迁云工具就是今天这篇文章想要分享的内容。 在帮助用户落实迁云方案之前，我们首先必须要回答至少3个问题：（1）ACK（阿里云容器服务Kubernetes）如何能保证用户业务的可靠性、稳定性、安全性和灵活性；（2）如何设计迁云方案把业务平滑地迁移到ACK；（3）应用如何做进一步改造来适配ACK提供的更强大的扩展能力。 1. ACK如何保证用户业务的可靠性、稳定性、安全性和灵活扩展性 首先，ACK是以阿里云可靠稳定的IaaS平台为底座的，有最大的弹性化与低廉成本和全球化接入的优势；其次，ACK本身处于阿里云的安全体系架构之下并从基础设施到容器运行时环境对容器集群有全维度的安全加固；过去几年我们很好地支撑了成百上千家大小企业的业务运行，有海量用户经验总结并经过双11验证；除此之外。ACK是在标准的Kubernetes基础上，对与用户息息相关的能力做了大幅提升，用户完全不需要担心会被某一家厂商绑定。 在我们过去帮助用户业务上云的案例中，绝大部分是自建Kubernetes集群迁移到ACK集群，与自建Kubernetes集群相比较，ACK在成本、弹性、IaaS高度融合、性能、安全加固以及实践经验等方面都有非常巨大的优势。 另外，ACK与阿里云的所有region保持一致，除了国内多个区域开服外，在东南亚、中东、欧洲、美东美西都有开服，完全可以满足用户开展全球业务的需求。 2. 整体迁云方案设计用户业务整体迁云的方案设计会涉及到集群规划、数据搬迁、监控切换、日志切换以及最终的生产流量切换或并网操作。 迁云到ACK需要做涉及到哪些组件、搬迁哪些数据、切换哪些服务等，都是需要用户又清晰的概念的。首先需要做集群规划，用户需要根据自己业务场景的不同来选择不同的机器类型，比如CPU机器还是GPU机器，比如虚拟服务器ECS还是神龙裸金属服务器等等，网络规划这部分会涉及到容器集群基础设施选择vpc内网网络还是经典网络，集群内pod之间进行通信模式是flannel模式还是terway模式等，在容量规划这部分，用户可以根据自己的成本以及预算规划一个可满足初期业务正常运行的容量即可，随后可以配置动态扩缩容随时弹缩集群规模；在安全防护提升这部分，有基础架构安全比如设置合理的安全组规则，有镜像安全比如使用私有镜像并定义镜像安全扫描，K8S应用安全管理比如设置不同服务间互相访问的网络安全策略等；监控切换这部分相对于用户自建Kubernetes会更加全维度和立体，从基础设施到容器运行时监控一应俱全，并可根据阈值设定触发报警通知；用户一般也会把自建的日志收集方案切换成阿里云上企业级的日志产品SLS；数据迁移是非常重要的一部分，这些数据包括数据库数据、存储数据、容器镜像等，我们会对接阿里云上企业级的粗出产品以及迁移工具，目的是为了保证数据迁云的可靠性、安全性；应用改造主要涉及的内容包括镜像地址的更新、服务暴露方式的优化以及存储盘挂载方式的更新适配；最后提供一个满足用户快速迭代上线产品的CICD方案。以上各个组件调试完毕后，我们就可以进行一部分生产流量的切换。以上从集群规划到生产流量切换便是用户业务迁移上云所需要涉及到的方方面面。 我们提供了一个企业容器化生命周期模型，这个模型是根据时间阶段和用户侧各个业务角色来划分的，比如业务架构师角色需要关心的是业务上云能给公司带来什么价值，在TCO和场景上会带来哪些优化，云平台在安全性以及计算、存储、网络能力上是否能满足当前业务需求；IT架构师负责规划当前业务需要的集群容量和规模以及网络选型等问题，剩下的就是系统管理员与应用管理员把迁云方案的各个细节落实下来。这个模型的主要核心关注点是让用户的业务上云后能更稳定、成本更低、效率更高。 全栈迁云架构思路分两种，一种是整体迁移，一种是平滑迁移。整体迁移是指用户应用全部迁移上云后，各个组件调试完毕、测试验收通过后，可以整体切换生产流量到线上集群，待线上集群上的业务稳定运行一段时间后再下线原有环境。平滑迁移是指用户可以使用线上ACK集群纳管线下节点，或者线上集群与线下集群混合组网对外提供服务，逐步改造业务组件上云后将原有环境下线。这两种方式相比，整体迁移更简单，平滑迁移响度复杂但对业务影响小，所以也需要根据用户的实际场景做选择。 容器化整体迁云这部分还有两个小场景，一个是用户从自建Kubernetes集群迁移到ACK，此场景下用户的应用已经做了很大一部分的云原生化改造，迁移工作相对来说会简单些，还有一部分用户的应用是传统应用，直接运行在虚拟机或者裸金属服务器上，没有做过任何云原生化的改造，对于这部分场景，我们也提供了相关工具或方案帮助用户进行云原生化的迁云改造，比如使用derrick项目可以自动检测源码项目类型并生成Dockerfile和用于应用部署编排的yaml文件，比如我们正在联合ECS SMC（迁云中心）开发的虚拟机转换容器镜像并运行在ACk集群中的能力。 为了帮助用户提高迁云的效率，我们也在持续积累和开源一些迁云工具。比ack-image-builder为用户提供创建ACK集群节点自定义镜像的模板并通过校验模块检查自定义镜像是否满足ACK集群要求；sync-repo能够帮助用户快速完成容器镜像批量迁移至ACR（容器镜像仓库服务）; velero能够帮助用户快速把其他云厂商后者自建Kubernetes集群下的完整应用迁移至ACK集群。 Velero迁移Kubernetes应用到ACK视频DEMO 在数据搬迁部分，可靠迁移是关键，根据用户数据类型的不同，我们会使用与之匹配的企业级迁移工具，比如数据在线迁移服务DOMS，比如OSS的迁移工具，还有离线海量数据迁移方案闪电立方等。 数据、应用迁云完成后，需要进一步适配监控、日志等组件，待各个组件调试完毕通过验收后，可以使用智能DNS进行生产流量的切割。 3. 应用改造和优化 对于应用改造和优化这部分，K8s到K8s的场景下，需要优化的是去适配自动扩容等自建K8s不具备的那些能力，在传统应用迁移到ACK的场景下，这部分的工作量会更大些，所以我们针对这个场景也输出了一些方案，比如类似于异地多活的方案，我们把用户传统应用环境，通常是虚拟机或者裸机环境集成到线上ACK部署的Istio网格中，逐步改造应用直至业务全部切换到线上ACK集群。 在应用逐步改造的这个过程中，会涉及到应用如何容器化、网络环境如何迁移以及数据迁移的问题，应用容器化这个问题，我们可以使用前面我提到过的一个服务叫做SMC迁云中心来完成虚拟机转换为容器镜像的过程，网络这部分可以通过iptables，External，CoreDNS PrivateZone等方式对IP地址DNS域名做处理，保持原先的逻辑IP和域名不变，并通过Istio实现网络虚拟路由和可观测性的管理。 4. 案例 接下来是部分迁云案例，有对高性能网络有特殊需求的用户，有做深度学习相关业务对大规模GPU机器有需求的用户，有要求裸金属机型服务器的用户等等。 5. 总结不同用户的不同业务场景在云原生化迁云方案的设计和落实上都有各自的差异性，不尽相同，需要结合ACK团队沉淀下来的最佳实践来快速做出评估和计划，并借助已有的一系列迁云工具快速完成业务从线下迁移上云的过程。 本文作者：流生 阅读原文 本文为云栖社区原创内容，未经允许不得转载。

阿里云数据库又被顶级机构点名了！ 近日，全球最知名的数据管理系统评测标准化TPC组织公布了数据库领域分析性能基准测试最新排名，阿里云超大规模分析型数据库AnalyticDB登上榜首，是全球首个通过TPC严格审计认证的云数据库产品。 简单来说，AnalyticDB是一款可以对数据进行在线统计和分析的数据库，帮助企业简单快速实时挖掘数据价值。登上TPC榜首，意味着其已经成为全球最快的实时数据仓库！ 目前，阿里云已经拥有国内最丰富的云数据库产品，AnalyticDB只是其中之一。 在多个数据库细分领域，阿里云已经实现了业界领先，并且已经集齐了一套最强阵容： 01在新零售场景中，数据分析师做市场趋势分析、业务在做广告投放时，都需要在PB级数据上依据不断变化的业务模型做分析探索，对业务发展方向进行决策。 而这就需要分析型数据库AnalyticDB的能力了，目前这款产品已经成为全球最快的实时数据仓库，在复杂分析场景中性能提升10倍，万亿数据多维分析仅需毫秒级。 02例如面对互联网大规模流量场景，阿里云拥有国内首款云原生数据库POLARDB，它最大的特点就是拥有极强的弹性能力，能大能小，解决了传统数据库昂贵、扩展性差、技术复杂、迭代慢的瓶颈。 技术方面，也采用了多个领先技术：容器虚拟化技术、存储与计算分离、共享分布式块存储技术，企业只需5分钟即可实现缩扩容，计算能力最高可扩展至1000核，存储容量最高可达100TB。被认为是云时代企业数据库的最佳选择。 03还有一类是擅长多度关系数据查询的。在金融欺诈检测场景中，图数据库可快速通过贷款联系人（或者联系人的联系人）信用信息，对用户进行信用评分，如果评分较低，则拒绝贷款或者提升利率。 阿里云GDB就具备这样的能力，GDB是国内首个云原生图数据库，可以对高度互连的数据集进行深度优化，用最短代码实现多度关系数据的查询与存储，提升查询效率10倍以上，查询时间降低至毫秒级。 04作为阿里云最早的云数据库产品，RDS已经成长为业界功能最丰富的数据库，支持MySQL、SQL Server、PostgreSQL 、MariaDB等主流数据库，可以满足不同场景的需求。 05传统数据库要上云，最关键的一步是保障数据库高效可靠地迁移。因为数据库承载着企业核心业务，但传统的数据库迁移工具要求数据库在迁移中必须停服，极大影响业务。 阿里云数据传输服务DTS大幅提升了数据库上云的速度，其最大的特点是采用分布式并发架构、智能分片、并行抓取技术，数据迁移最快可达100Mb/S，支持18种数据源，百PB级数据迁移业界最快。 大家不妨脑洞一下，看完这五款数据库产品，你想到了什么超级英雄？ 本文作者：阿里云头条阅读原文 本文为云栖社区原创内容，未经允许不得转载。

AnalyticDB for PostgreSQL（简称：ADB for PG）对Teradata语法有着很好的兼容，将Teradata应用迁移到ADB for PG，只需进行有限的修改。本文介绍将Teradata应用迁移到ADB for PG应该注意的事项。 1 建表语句我们通过一个例子比较ADB for PG和Teradata的建表语句。对于如下的Teradata建表SQL语句， CREATE MULTISET TABLE test_table,NO FALLBACK , NO BEFORE JOURNAL, NO AFTER JOURNAL, CHECKSUM = DEFAULT, DEFAULT MERGEBLOCKRATIO ( first_column DATE FORMAT 'YYYYMMDD' TITLE '第一列' NOT NULL, second_column INTEGER TITLE '第二列' NOT NULL , third_column CHAR(6) CHARACTER SET LATIN CASESPECIFIC TITLE '第三列' NOT NULL , fourth_column CHAR(20) CHARACTER SET LATIN CASESPECIFIC TITLE '第四列' NOT NULL, fifth_column CHAR(1) CHARACTER SET LATIN CASESPECIFIC TITLE '第五列' NOT NULL, sixth_column CHAR(24) CHARACTER SET LATIN CASESPECIFIC TITLE '第六列' NOT NULL, seventh_column VARCHAR(18) CHARACTER SET LATIN CASESPECIFIC TITLE '第七列' NOT NULL, eighth_column DECIMAL(18,0) TITLE '第八列' NOT NULL , nineth_column DECIMAL(18,6) TITLE '第九列' NOT NULL )PRIMARY INDEX ( first_column ,fourth_column )PARTITION BY RANGE_N(first_column BETWEEN DATE '1999-01-01' AND DATE '2050-12-31' EACH INTERVAL '1' DAY );CREATE INDEX test_index (first_column, fourth_column) ON test_table;可以修改成ADB for PG的建表语句： ...

作者：王相 本文为 DM 源码阅读系列文章的第七篇，在 上篇文章 中我们介绍了 relay log 的实现，主要包括 relay log 目录结构定义、relay log 数据的处理流程、主从切换支持、relay log 的读取等逻辑。本篇文章我们将会对 DM 的定制化数据同步功能进行详细的讲解。 在一般的数据同步中，上下游的数据是一一对应的，即上下游的库名、表名、列名以及每一列的值都是相同的，但是很多用户因为业务的原因希望 DM 在同步数据到 TiDB 时进行一些定制化的转化。下面我们将主要介绍数据同步定制化中的库表路由（Table routing）、黑白名单（Black & white table lists）、列值转化（Column mapping）、binlog 过滤（Binlog event filter）四个主要功能的实现。值得注意的是，由于其他一些工具（例如 TiDB Lightning 和 TiDB Binlog）也需要类似的功能，所以这四个功能都以 package 的形式维护在 tidb-tools 项目下，这样方便使用和维护。 库表路由（Table routing）库表路由顾名思义就是对库名和表名根据一定的路由规则进行转换。比如用户在上游多个 MySQL 实例或者 schema 有多个逻辑上相同的表，需要把这些表的数据同步到 TiDB 集群的同一个表中，这个时候就可以使用 table-router 功能，如下图所示： 该功能实现在 pkg/table-router 中，库表路由的规则定义在结构 TableRule 中，其中的属性 SchemaPattern 和 TablePattern 用于配置原库名和表名的模式，TargetSchema 和 TargetTable 用于配置目标库和表名，即符合指定 pattern 的库和表名都将转化成目标库名和表名。 ...

摘要： 洞见前沿技术趋势，见证阿里云数据库成长历程。在DTCC这场数据库领域从业人士的年度盛会和交流平台上，来看看阿里云技术大牛们都带来了怎样的饕餮盛宴？8场议题的直播回顾、干货PPT下载及分享实录汇总如下2019年5月8日-5月10日，由国内知名IT技术社区主办的数据库技术交流盛会——DTCC 2019在北京新云南皇冠假日大酒店召开。数据风云，十年变迁，DTCC见证并铭记了国内数据库技术的关键成长历程。作为DTCC的老朋友和全球领先的云计算厂商，阿里云数据库团队受邀参加本次技术盛会，不仅派出了重量级嘉宾阵容，还为广大数据库业内人士和行业用户奉上了8场精彩议题。 洞见前沿技术趋势，见证阿里云数据库成长历程。在这场数据库领域从业人士难得的年度盛会和交流平台上，来看看阿里云技术大牛们都带来了怎样的饕餮盛宴。 8场议题的直播回顾、干货PPT下载及分享实录汇总如下： 1、阿里云李飞飞：云原生新战场，我们如何把握先机？直播回顾：https://yq.aliyun.com/live/1043?utm_content=g_1000061144 分享实录文字版：https://yq.aliyun.com/articles/703885?utm_content=g_1000061145 会上，阿里云POLARDB荣膺2019中国数据库年度最佳创新产品 相关阅读见：https://yq.aliyun.com/articles/702310?utm_content=g_1000061146 2、深度解码阿里数据库实现 数据库内核——基于HLC的分布式事务实现深度剖析直播回顾：https://yq.aliyun.com/live/1045?utm_content=g_1000061147 分享实录文字版：https://yq.aliyun.com/articles/703552?utm_content=g_1000061148 PPT下载：https://yq.aliyun.com/download/3566?utm_content=g_1000061149 3、海量数据毫秒级分析的背后——《阿里超大规模实时数仓架构挑战与实践解析》直播回顾：https://yq.aliyun.com/live/1047?utm_content=g_1000061150 分享实录文字版：https://yq.aliyun.com/articles/702765?utm_content=g_1000061151 PPT下载：https://yq.aliyun.com/download/3553?utm_content=g_1000061152 4、前沿技术应用知多少? 阿里云图数据库GDB带你探索互联数据的奥秘直播回顾：https://yq.aliyun.com/live/1050?utm_content=g_1000061153 分享实录文字版：https://yq.aliyun.com/articles/703444?utm_content=g_1000061154 PPT下载：https://yq.aliyun.com/download/3555?utm_content=g_1000061155 5、把握数据库发展趋势 DBA应如何避免“踩坑”?直播回顾：https://yq.aliyun.com/live/1046?utm_content=g_1000061156 分享实录文字版：https://yq.aliyun.com/articles/703521?utm_content=g_1000061157 PPT下载：https://yq.aliyun.com/download/3562?utm_content=g_1000061158 6、阿里云TSDB: 教你解锁时序时空数据库的种种黑科技直播回顾：https://yq.aliyun.com/live/1044?utm_content=g_1000061159 分享实录文字版：https://yq.aliyun.com/articles/703542?utm_content=g_1000061160 PPT下载：https://yq.aliyun.com/download/3563?utm_content=g_1000061161 7、云时代数据库迁移 & 容灾技术新进展与应用直播回顾：https://yq.aliyun.com/live/1048?utm_content=g_1000061162 分享实录文字版：https://yq.aliyun.com/articles/703544?utm_content=g_1000061163 PPT下载：https://yq.aliyun.com/download/3564?utm_content=g_1000061164 8、NoSQL数据库最新发展趋势 如何拥有居家必备的企业级能力？直播回顾：https://yq.aliyun.com/live/1049?utm_content=g_1000061165 分享实录文字版：https://yq.aliyun.com/articles/703549?utm_content=g_1000061166 PPT下载：https://yq.aliyun.com/download/3565?utm_content=g_1000061167 本文作者：七幕阅读原文 本文为云栖社区原创内容，未经允许不得转载。

作者：张学程 本文为 DM 源码阅读系列文章的第六篇，在 上篇文章 中我们介绍了 binlog replication 处理单元的实现，对在增量复制过程中 binlog event 的读取、过滤、路由、转换以及执行等逻辑进行了分析。 本篇文章我们将会对 relay 数据处理单元的实现进行详细的讲解。这个单元的作用是从上游 MySQL/MariaDB 读取 binlog event 并写入到本地的 relay log file 中；当执行增量复制任务时，binlog replication 处理单元将读取 relay log file 中的 event 并在进行解析后复制到下游的 TiDB 中。本篇文章的内容包括 relay log 目录结构定义、relay log 数据的处理流程、主从切换支持、relay log 的读取等逻辑。 值得注意的是，由于我们近期正在对 relay 处理单元进行重构，因此源码中会同时包含重构前后的相关代码实现。 relay log 目录结构一个已经进行过一次主从切换的 relay log 目录结构大致如下： <deploy_dir>/relay_log/|-- 7e427cc0-091c-11e9-9e45-72b7c59d52d7.000001| |-- mysql-bin.000001| |-- mysql-bin.000002| |-- mysql-bin.000003| |-- mysql-bin.000004| `-- relay.meta|-- 842965eb-091c-11e9-9e45-9a3bff03fa39.000002| |-- mysql-bin.000001| `-- relay.meta`-- server-uuid.index在 relay log 目录下，主要包含以下几类文件或文件夹数据： ...

5月21日，阿里云PolarDB发布重大更新，提供传统数据库一键迁移上云能力，可以帮助企业将线下的MySQL、PostgreSQL和Oracle等数据库轻松上云，最快数小时内迁移完成。据估算，云上成本不到传统数据库的1/6。目前，已有约40万个数据库迁移到阿里云上。 阿里云方面表示，该产品实现了两大技术突破：通过自研超低延迟文件系统PolarFS大幅降低数据跨网络的延迟，并且开发了一种全新的共识协议ParallelRaft，提升系统吞吐量。在此之前，PolarFS的研究成果已发表在数据库顶级会议 VLDB 2018 《PolarFS: An Ultra-low Latency and Failure Resilient Distributed File System for Shared Storage Cloud Database》。 企业在使用传统商业数据库时，经常会面临授权费用贵、硬件成本高、架构与运维复杂、迁移难度大等问题，此次云原生数据库PolarDB的重大更新针对此类痛点，实现一键快速迁移，并提供云上的完整生态服务。 此外，产品还具备三大亮点，满足企业在数字时代海量的数据存储需求：1、单实例规格最大达88核710GB；2、业内最快单节点读写速度100万QPS；3、实现三份数据存储实时同步0延迟。除性能领先外，云上数据库成本也低于传统数据库，不到后者的1/6。 PolarDB是阿里云在2018年正式商业化的云原生数据库，采用存储计算分离、软硬一体化设计，具备快速弹性能力、超大规格、超高可靠性以及两倍于AWS Aurora的性能。目前已是阿里云上增长最快的数据库产品。 随着移动互联网、物联网的发展，数据量剧增。企业上云也成大势所趋，企业上云意愿达84%，云也对数据库提出了更高的扩展性和可用性要求。 因昂贵、扩展性差、技术复杂、迭代慢，传统商业数据库饱受诟病。与传统数据库相反，云原生数据库天然拥有云计算的弹性能力，兼具开源数据库的易用、开放特点，及传统数据库的管理和处理性能优势，是云时代下企业数据库的最佳选择。 在全球范围内，一场替换传统数据库的行动正在进行。早在2013年，阿里巴巴就将最后一台Oracle数据库从其淘宝核心系统中下线。亚马逊也公开表示，将在2020年彻底放弃Oracle数据库。 阿里云智能数据库事业部负责人李飞飞表示，云原生数据库在成本、灵活度、安全、技术进化层面都优于传统数据库，传统数据库会像马车一样被淘汰。 阿里云拥有国内最丰富的云数据库产品，目前已有约40万个数据库迁移到阿里云上，涵盖金融、电信、制造、物流等领域的龙头企业。在Gartner发布的2018年数据库魔力象限中，阿里云是国内首个进入挑战者象限的中国公司。 阿里云数据库的技术研究也在国际上崭露头角。PolarDB相关论文入选今年的国际顶级数据库会议SIGMOD，这是阿里云数据库连续第二年入选该学术会议。 本文作者：阿里云头条阅读原文 本文为云栖社区原创内容，未经允许不得转载。

作者：Dan本文转载自公众号「白噪声OG」。经历了上礼拜漫长的上线周期，终于有时间总结一下期间发生的故事。TiDB 是一款非常优秀的国产分布式 NewSQL 数据库，因其支持水平扩展性、强一致性、高可用性，从 18 年 3 月起已在国内银行的账务、支付类核心系统得到应用。 临近年中，银行重要系统的建设进入投产冲刺阶段，本次上线又有多个系统对接 TiDB，为了优化集群资源分配，引发了这次分享的主题——线上系统 TiKV 的缩容、region 的迁移，本文主要针对本次 TiKV 的缩容、迁移过程进行梳理总结。 TiDB 数据库的扩容已在官方文档进行了详细的说明（https://pingcap.com/docs-cn/op-guide/horizontal-scale/）并被各路大咖广泛提及，但缩容迁移并在银行交易系统上的实践却少有分享，这也是本文的目的之一。 进入主题，先交代下环境，服务器集群采用 NVMe+SSD 的存储方案构建了 16 个 TiKV 实例，作为重要的核心支付类系统，两地三中心五副本不可少，每个 TiKV 上 8K+ 个 region。整个迁移过程历时 5 个小时，过程中没有停止系统对外服务，很是顺滑平稳。 接下来还是看一下迁移的过程： （一） TiKV 采用 Raft 一致性算法保证副本强一致性，迁移过程本质上是扩容的逆过程，确定下线的 TiKV 打上 label 后，将 region 搬移到最终保留下来的 TiKV 上。 （二） 接下来聚焦 region 1 的 Raft Group，对其副本进行搬移，实际上所有 region 的数据是一样的，只是在保留的 TiKV 内进行 region 数据的复制，新产生的副本由于数据不完整，作为 Raft Group 中的 learner。 （三） Learner 创建后，PD 会在这样的一个 Raft Group（5 个全副本 region + 2 个 learner）中发起选举： ...

轻松筹首创了“大病救助”模式，帮助了众多病患在第一时间解決了医疗资金等问题，为了从源头解决了医疗资金问题。而在轻松筹这样全球5.5亿用户信赖的大病筹款平台的背后，是日益增长的各种数据。面对这样数据量所造成的巨大挑战，阿里云POLARDB是如何帮助轻松筹践行“善DNA”的呢？本文就为大家分享。 关于轻松筹2014年9月,轻松筹成立。“轻松筹”作为公司旗下的首要产品,“善DNA”可谓贯穿了整个发展历程。轻松筹将目标聚焦在公众健康保障领域，各功能板块都与百姓的健康息息相关。由轻松筹首创的“大病救助”模式帮助众多病患在第一时间解決了医疗资金等问题。 为了从源头解决医疗资金问题,轻松筹于2016年4月推出了“轻松互助”业务,其目的在于抱团抵抗大病风险,一人患病,众人均推救助金。并与多家保险公司达成合作，推出多款会员定制的保险产品，至此,轻松筹“全民健康保障体系”正式建成。 目前,轻松筹在自主研发的“区块链”技术的加持下,再一次开创了行业先河。“阳光链”将大病救助、公益机构及互助行动的捐赠记录、资金流向公开透明，为公益事业及大病救助的发展指明了新方向。历时4年,轻松筹体系(包含大病救助、轻松互助、轻松e保、轻松公益、轻松健康)在全球183个国家和地区的用户总数超过5.5亿、筹款总额超过255亿元。 轻松筹的“大病救助”场景由轻松筹首创的“大病救助”模式，通过社交强关系为大病患者提供高效便捷的筹款渠道，目前已经帮助235万个大病家庭，筹集了255亿元善款。 轻松筹大病救助平台能够为多达千万的用户提供筹款服务，每周增加的相关数据量多达10GB，包括发起筹款的项目信息、用户分享信息、订单数据等，不断增加的数据，很容易在目前的RDS数据库上，达到存储的上限。轻松筹通过将数据迁移至阿里云POLARDB，很好的解决了存储容量和性能的瓶颈。 轻松筹基于阿里云POLARDB的简单架构设计轻松筹最为看重就是阿里云POLARDB存储容量大和免分库分表的特性。因为阿里云POLARDB采用了集群架构，并且采用了计算和存储分离以及读写分离的机制，所以其存储容量最高能够支持100TB，用户无需因为单机容量的天花板而去购买多个MySQL实例做分片，并且也不需要考虑分库分表，因此就简化应用的开发，同时也降低了运维的负担。 其次，轻松筹还看中了POLARDB强大的读写分离能力。当应用程序使用集群地址时，POLARDB通过内部的代理层对外提供服务，应用程序的请求都先经过代理，然后才访问到数据库节点。Proxy不仅可以做安全认证和保护，还可以解析SQL，把写操作发送到主节点，把读操作均衡地分发到多个只读节点，实现自动的读写分离。对于轻松筹的小程序而言，在后台使用POLARDB集群就像使用一个单点的MySQL数据库一样简单。 此外，在性能方面，阿里云POLARDB利用基于Redo的物理复制代替基于Binlog的逻辑复制，提升主备复制的效率和稳定性，即使对大表进行加索引、加字段等DDL操作，也不会造成数据库的延迟，能够实现毫秒级延迟。此外，POLARDB内置并行查询引擎，对执行时长超过1分钟的复杂分析类SQL加速效果明显。这样的性能优势能够很好地满足轻松筹的需求。 POLARDB助力“大病救助”平台数据管理效率提升 在阿里云POLARDB的强大能力的基础之上，轻松筹的“大病救助”平台的数据管理效率有了非常大的提升，其主要体现在以下三个方面： 自适应数据增长 轻松筹的大病筹款项目随着时间的累积，每年以上T以上的结构化数据进行新增进行存储。每年新增数据表达到数百个，单表数据量更是达到亿级别。由于POLARDB采用分布式存储服务，能够根据数据增长自适应增加存储空间，按照实际数据使用量进行计费，不必为数据容量的限制和升级所担忧。 724 高可用服务 阿里云POLARDB采用自带读写分离的Active-Active多活高可用集群架构 ，能够更好的监测故障和进行快速故障自动恢复，确保99.95%的高可用服务的同时，集群自带只读节点，使得系统的聚合读取性能成倍提升。 即时数据检索和查询 大病筹款的数据需要周期性批量写入到POLARDB，而同时又需要支持即时的检索查询和分析处理，POLARDB的读写分离架构，很好的支撑了这类场景。同时，POLARDB还能够在几分钟以内在线增加只读节点，进一步提升系统的吞吐处理能力，结合读写分离连接地址，自动进行请求的识别转发，通过自适应负载均衡处理，让集群的计算力能够发挥到最大，消除了计算瓶颈。 本文作者：桐碧2018阅读原文 本文为云栖社区原创内容，未经允许不得转载。

全面云化的时代已经到来，面对一系列的新技术和挑战，数据库市场将面临怎样的变革？作为云服务提供商，如何帮助更多的企业级用户把握“云”潮，提供最高效、最具价值的数据库解决方案？日前，在阿里云峰会·北京站的数据库专场上，阿里巴巴集团副总裁、达摩院首席数据库科学家、阿⾥云智能事业群数据库产品事业部总负责⼈李飞飞针对下一代云原生数据库的技术与挑战进行了精彩分享。数据库发展与技术演进之路根据DB-Engine 2019年1月份的数据库市场趋势分析，关系型数据库依旧占据着最核心的市场份额。与此同时，数据库市场也在不断细分，图数据库、文档数据库以及NoSQL等数据库细分市场正在崛起。另一大趋势则是：以Oracle、DB2和Microsoft SQL Server三大巨头为代表的传统商业数据库所占据的市场份额不断下降，而开源和第三方数据库市场持续增长。数据库技术诞生至今，虽然已经历40多年的发展历程，但仍旧处于蓬勃发展的时期。如今，各大云计算厂商也达成了共识：数据库是连接IaaS和云上智能化应用的重要组成部分，因此从数据的产生、存储以及消费等各个环节，云产商都需要提升全链路的能力，进而满足用户连接IaaS和智能化应用的需求。随着数据库技术的不断发展，不仅出现了OLTP系统来实现事务的处理，可以实现对交易数据的实时记录；还出现了OLAP系统，借助OLAP系统可实现对于海量数据的实时分析。除此之外，还需要各类的数据库服务和管控工具支持核心的OLTP和OLAP系统。在此基础之上，针对半结构化数据和非结构化数据，NoSQL数据库解决方案应运而生。上世纪70年代末到80年代初，诞生了关系型数据库，产生了SQL查询语言以及OLTP交易处理系统。随着数据的爆发式增长以及复杂分析需求的出现，诞生了数据仓库，以及OLAP在线分析处理系统以及ETL等数据处理技术。技术发展到今天，图、文档以及时空、时序等多元异构数据量持续增长，因此也对应地出现了关系型数据库之外的NoSQL和NewSQL数据库系统。云原生时代 我们需要怎样的数据库？传统数据库往往采用单节点架构，而到了如今的云原生时代，云原生数据库通常会采用共享存储的架构方式。阿里云POLARDB所采用的就是共享存储架构，通过高速网络构建共享存储，在此之上实现存储与计算的分离，进而可以快速弹性扩容出多个计算节点。与此同时，POLARDB还可以根据用户的具体需求在存储和计算两个维度迅速地实现扩缩容。而对于用户而言，无需修改任何业务逻辑，就可以使用基于共享存储的POLARDB数据库，可以实现无侵入式迁移。除了云原生的共享存储技术之外，面对高并发、海量数据访问的挑战，也需要借助分布式架构来解决，比如为了应对每年的双11大促，阿里巴巴自身就需要去探索分布式架构。此外，针对数据的多模多态需求，阿里云也希望在用户侧提供不同查询接口，比如SQL。在存储侧，阿里云希望能够支持用户将数据存储到不同地方，并通过像SQL这样的统一接口实现对不同数据类型的统一查询访问。目前，阿里云所提供数据湖服务就是针对上述场景所演进来的云原生技术。正如前面所提到的OLTP和OLAP系统，传统的解决方案希望将读写冲突隔离开，让OLTP负责事务处理，让OLAP负责海量数据的分析任务。而在云原生时代，阿里云会借助新硬件所带来的技术红利，尽可能降低数据迁移的成本，将事务处理和数据分析整合在同一个引擎中，通过一套系统为用户无缝解决两种问题。阿里云目前已经服务了大量企业级客户，这些客户通过虚拟化、存储与计算分离来使用阿里云所提供的云资源池。因此，我们需要对于云上全部资源进行智能化监控和调配，做到快速响应，并且为用户提供最高质量的服务。而智能化的背后需要利用机器学习以及人工智能技术，从数据迁移、数据保护、弹性调度等各个维度实现自感知、自决策、自恢复以及自优化。在云原生时代，另外一个重要技术就是软硬件一体化设计。新硬件的发展为数据库系统带来了许多可不断利用的技术红利，比如RDMA网络、SSD、NVM、GPU、IPG加速等。阿里云的POLARDB共享存储就利用了RDMA网络，因此可以做到像本地节点一样快速访问远程数据库节点。对于很多云上的客户而言，可能也有金融级高可用的需求。利用高可用协议，阿里云数据库可以采用三副本架构，在本地可以实现数据库之间的无缝实时切换，在异地也可以满足不同用户对于灾备的需求，借助Binlog技术实现异地数据同步，实现金融级高可用。此外，云上用户对数据的安全性尤为看重，阿里云数据库服务从数据落盘开始，就提供了加密技术，确保全链路的数据安全。阿里云数据库服务：全域布局自主可控 兼具创新与商用价值阿里云数据库所提供的工具类产品包括数据备份、数据迁移、数据管理、混合云数据管理以及智能化诊断与优化系统等，可以帮助客户实现快速上云并且打造混合云解决方案。我们提供的核心引擎产品中，既有自主可控的自研产品，也有第三方以及开源的产品。希望通过商业数据库以及开源产品为用户提供丰富的选择，同时也希望将云计算的技术红利整合到自研数据库产品中去，进一步做深做透，真正地帮助客户解决应用第三方或者开源数据库所无法解决的痛点和问题。在OLTP方向，阿里云数据库所提供的核心产品是POLARDB以及其分布式版本POLARDB X。除此之外，阿里云也提供主流的MySQL、PostgreSQL、SQLServer以及针对于Oracle兼容的PPAS等一系列服务。针对OLAP系统，我们的核心产品是AnalyticDB、针对多源异构数据所提供的数据湖服务DLA，以及针对IoT场景的时序时空数据库TSDB。而在NoSQL领域，阿里云则提供了丰富的第三方数据库产品供客户选择，比如HBase、Redis、MongoDB以及阿里云自研的图数据库GDB等。阿里云数据库的管控平台与全链路监控服务为用户提供了智能化的全链路检测与分析，保障阿里云数据库能够为用户提供最高级别的Service Level。阿里云帮助客户打造了一条线上线下混合云数据存储的链路，从客户迁移上云开始，其可以选择阿里云DTS服务进行实时的数据上传和同步。数据上云之后，客户可选择POLARDB等云原生数据库产品进行存储，也可以借助DLA或者AnalyticDB等产品进行数据分析。而针对特定场景进行数据分析可以选用文档数据库、图数据库或者时序时空数据库等解决方案，可以借助DTS系统实现线上线下的数据同步备份，并且还可以借助HDM来进行混合云数据库管理。此外，阿里云数据库服务还提供了数据库管理套件，可以支撑用户对数据库进行管理和开发，使得管理和开发流程更为高效。这里主要为大家介绍两种云原生数据库产品，POLARDB和AnalyticDB。POLARDBPOLARDB利用RDMA网络实现了高效的共享分布式存储，借助于共享存储技术，多个计算节点中可以实现“一写多读”，并且可以根据客户的工作量需求，快速弹出多个只读节点来满足客户在高峰时刻对于计算的需求，同时也可以在存储节点上实现快速缩扩容。针对客户的应用场景以及其业务峰值峰谷的波动情况，POLARDB可以做到按量按需使用和计费，进而大大地提升了客户的数据库使用效率，节省了所需要成本。总体而言，POLARDB就是一个超级MySQL，后续POLARDB还会陆续推出兼容PostgreSQL和Oracle的版本。在一些场景下，用户需要面对高并发和海量数据访问的挑战，因此需要突破共享存储的容量上限。分布式架构的POLARDB X则利用Sharding Partition解决方案实现了存储容量的无限水平扩展。POLARDB X分布式版本也会在后续进行公测，欢迎大家试用。AnalyticDB对海量数据进行分析的时候，读写会产生一定的冲突。如果需要读取大量数据并进行分析将会极为复杂，因此推荐大家使用阿里云的实时交互式分析数据库系统AnalyticDB。AnalyticDB最核心的特点是具有支持高吞吐写入的能力，并且具有针对于行列存储所研发的存储引擎，因此可以实现实时的交互式分析。在海量数据以及高并发场景下，AnalyticDB在响应时间方面的表现都非常优秀。AnalyticDB兼容了MySQL生态，因此可以将MySQL里面的数据直接导入AnalyticDB中，可以实现对上百亿级别的数据的毫秒级查询以及百万TPS级别的写入。数据传输云服务DTS除了核心的云原生数据库产品，我们还有多款数据库工具型产品，比如数据传输云服务DTS。DTS所解决的痛点是云下客户上云所需要进行的数据传输问题，以及其在上云之后，云上与云下数据库或者从TP到AP系统之间进行实时的数据同步问题。利用DTS，用户可以实现快速、高效地增量数据同步，保证了实时数据一致。DTS还提供了数据订阅能力，可以通过不同的协议和接口来接入更多不同的数据源。数据库家族迎来新成员：图数据库GDB这里为大家介绍一款阿里云新的数据库产品——阿里云图数据库GDB，该产品目前正在阿里云官网进行公测。GDB是一种支持属性图模型，用于处理高度连接数据查询与存储的实时可靠的在线数据库，其利用了大量的云原生技术，比如存储与计算分离等。GDB支持标准的图查询语言，兼容Gremlin语法，这一点与市场主流的图数据库保持一致。GDB另外一个最核心的特点就是支持实时更新、支持OLTP级别的数据一致性，能够帮助大家在对海量的属性图进行分析存储时保证数据的一致性。GDB具有服务高可用、易于维护等云原生数据库产品的特性。比较典型的应用场景有社交网络、金融欺诈检测、实施推荐等，同时GDB还支持知识图谱等形态以及神经网络等。以赋能客户为本：降本提效 无忧发展阿里云数据库团队的目标是为客户提供企业级的云原生数据库服务，利用自身全域布局、自主可控的技术为企业客户提供快速数据上云、云上云下统一数据管理以及数据安全等服务。举例而言，阿里云数据库服务目前在杭州等城市支撑了像城市大脑这样复杂的应用，其既需要存储结构化数据也需要存储非结构数据，并且对于OLTP、OLAP、工具类产品等都提出了巨大的挑战，而借助阿里云AnalyticDB、POLARDB、DTS等利用了云原生技术的产品可以无缝地支撑城市大脑这样的复杂应用场景。以POLARDB为例，该产品于2018年8月份进行公测，2018年的年底进行商业化，到目前为止实现了在公有云平台上的快速增长。POLARDB呈现快速增长背后的核心原因就是阿里云真正地帮助客户解决自身的痛点问题，不是利用新技术来“造完锤子找钉子”，而是真正地“看到钉子再去造锤子”。POLARDB最为核心的特点就是云原生、分钟级别的弹性存储和计算、高性价比、灵活弹性的使用计费方式、高并发能力，可快速扩容多个只读节点、大容量支持、通过共享分布式存储做到了类似单机数据库的体验，对用户的业务逻辑无侵入，并且高度兼容MySQL。AnalyticDB则是一个实时交互式分析系统，无论是自制数据还是从大数据系统中获取的存储数据，都可以借助DTS工具将其迁移到AnalyticDB集群上，进行深入的商业分析、可视化以及交互式查询等。AnalyticDB能够支持上百个表的连接查询，可为客户提供毫秒级的查询服务。如今，无数用户正在阿里云上使用POLARDB和AnalyticDB这样的云原生数据库，云原生数据库也正在真正地改变客户在应用中所遇到的痛点，为他们带来更多的业务价值。总结而言，云原生时代出现了一系列的新技术和新挑战。面对这些挑战，需要对于数据库内核产品、管控平台以及数据库工具进行有机整合，才能够为客户提供最高效、最具有价值的解决方案。阿里云诚挚地邀请大家体验自身的产品和技术，希望能够与更多的客户一起合作，解决问题，也希望更多的开发者和生态合作伙伴能够基于阿里云的数据库服务和产品打造针对特定行业和领域的深度解决方案，使得云原生时代的数据库市场更加繁荣。本文作者：七幕阅读原文本文为云栖社区原创内容，未经允许不得转载。

作者：张学程本文为 DM 源码阅读系列文章的第二篇，第一篇文章 简单介绍了 DM 源码阅读的目的和规划，以及 DM 的源码结构以及工具链。从本篇文章开始，我们会正式开始阅读 DM 的源码。本篇文章主要介绍 DM 的整体架构，包括 DM 有哪些组件、各组件分别实现什么功能、组件之间交互的数据模型和 RPC 实现。整体架构通过上面的 DM 架构图，我们可以看出，除上下游数据库及 Prometheus 监控组件外，DM 自身有 DM-master、DM-worker 及 dmctl 这 3 个组件。其中，DM-master 负责管理和调度数据同步任务的各项操作，DM-worker 负责执行具体的数据同步任务，dmctl 提供用于管理 DM 集群与数据同步任务的各项命令。DM-masterDM-master 的入口代码在 cmd/dm-master/main.go，其中主要操作包括：调用 cfg.Parse 解析命令行参数与参数配置文件调用 log.SetLevelByString 设置进程的 log 输出级别调用 signal.Notify 注册系统 signal 通知，用于接受到指定信号时退出进程等调用 server.Start 启动 RPC server，用于响应来自 dmctl 与 DM-worker 的请求在上面的操作中，可以看出其中最关键的是步骤 4，其对应的实现代码在 dm/master/server.go 中，其核心为 Server 这个 struct，其中的主要 fields 包括：rootLis, svr：监听网络连接，分发 RPC 请求给对应的 handler。workerClients：维护集群各 DM-worker ID 到对应的 RPC client 的映射关系。taskWorkers：维护用于执行各同步（子）任务的 DM-worker ID 列表。lockKeeper：管理在协调处理 sharding DDL 时的 lock 信息。sqlOperatorHolder：管理手动 skip/replace 指定 sharding DDL 时的 SQL operator 信息。在本篇文章中，我们暂时不会关注 lockKeeper 与 sqlOperatorHolder，其具体的功能与代码实现会在后续相关文章中进行介绍。在 DM-master Server 的入口方法 Start 中：通过 net.Listen 初始化 rootLis 并用于监听 TCP 连接（借助 soheilhy/cmux，我们在同一个 port 同时提供 gRPC 与 HTTP 服务）。根据读取的配置信息（DeployMap），初始化用于连接到各 DM-worker 的 RPC client 并保存在 workerClients 中。通过 pb.RegisterMasterServer 注册 gRPC server（svr），并将该 Server 作为各 services 的 implementation。调用 m.Serve 开始提供服务。DM-master 提供的 RPC 服务包括 DM 集群管理、同步任务管理等，对应的 service 以 Protocol Buffers 格式定义在 dm/proto/dmmaster.proto 中，对应的 generated 代码在 dm/pb/dmmaster.pb.go 中。各 service 的具体实现在 dm/master/server.go 中（Server）。DM-workerDM-worker 的结构与 DM-master 类似，其入口代码在 cmd/dm-worker/main.go 中。各 RPC services 的 Protocol Buffers 格式定义在 dm/proto/dmworker.proto 中，对应的 generated 代码在 dm/pb/dmworker.pb.go 中，对应的实现代码在 dm/worker/server.go 中（Server）。DM-worker 的启动流程与 DM-master 类似，在此不再额外说明。Server 这个 struct 的主要 fields 除用于处理 RPC 的 rootLis 与 svr 外，另一个是用于管理同步任务与 relay log 的 worker（相关代码在 dm/worker/worker.go 中）。在 Worker 这个 struct 中，主要 fields 包括：subTasks：维护该 DM-worker 上的所有同步子任务信息。relayHolder：对 relay 处理单元相关操作进行简单封装，转发相关操作请求给 relay 处理单元，获取 relay 处理单元的状态信息。relayPurger：根据用户配置及相关策略，尝试定期对 relay log 进行 purge 操作。数据同步子任务管理的代码实现主要在 dm/worker/subtask.go 中， relay 处理单元管理的代码实现主要在 dm/worker/relay.go 中，对 relay log 进行 purge 操作的代码实现主要在 relay/purger pkg 中。在本篇文章中，我们暂时只关注 DM 架构相关的实现，上述各功能的具体实现将在后续的相关文章中展开介绍。Worker 的入口方法为 Start，其中的主要操作包括：通过 w.relayHolder.Start 启动 relay 处理单元，开始从上游拉取 binlog。通过 w.relayPurger.Start 启动后台 purge 线程，尝试对 relay log 进行定期 purge。其他的操作主要还包括处理 Server 转发而来的同步任务管理、relay 处理单元管理、状态信息查询等。dmctldmctl 的入口代码在 cmd/dm-ctl/main.go，其操作除参数解析与 signal 处理外，主要为调用 loop 进入命令处理循环、等待用户输入操作命令。在 loop 中，我们借助 chzyer/readline 提供命令行交互环境，读取用户输入的命令并输出命令执行结果。一个命令的处理流程为：调用 l.Readline 读取用户输入的命令判断是否需要退出命令行交互环境（exit 命令）或需要进行处理调用 ctl.Start 进行命令分发与处理dmctl 的具体命令处理实现在 dm/ctl pkg 中，入口为 dm/ctl/ctl.go 中的 Start 方法，命令的分发与参数解析借助于 spf13/cobra。命令的具体功能实现在相应的子 pkg 中：master：dmctl 与 DM-master 交互的命令，是当前 DM 推荐的命令交互方式。worker：dmctl 与 DM-worker 交互的命令，主要用于开发过程中进行 debug，当前并没有实现所有 DM-worker 支持的命令，未来可能废弃。common：多个命令依赖的通用操作及 dmctl 依赖的配置信息等。每个 dmctl 命令，其主要对应的实现包括 3 个部分：在各命令对应的实现源文件中，通过 New*Cmd 形式的方法创建 cobra.Command 对象。在 dm/ctl/ctl.go 中通过调用 rootCmd.AddCommand 添加该命令。在各命令对应的实现源文件中，通过 ***Func 形式的方法实现参数验证、RPC 调用等具体功能。任务管理调用链示例让我们用一个启动数据同步任务的操作示例来说明 DM 中的组件交互与 RPC 调用流程。用户在 dmctl 命令行交互环境中输入 start-task 命令及相应参数。dmctl 在 dm/ctl/ctl.go 的 Start 方法中进行命令分发，请求 dm/ctl/master/start_task.go 中的 startTaskFunc 处理命令。startTaskFunc 通过 cli.StartTask 调用 DM-master 上的 RPC 方法。DM-master 中的 Server.StartTask 方法（dm/master/server.go）响应来自 dmctl 的 RPC 请求。Server.Start 从 workerClients 中获取任务对应 DM-worker 的 RPC client，并通过 cli.StartSubTask 调用 DM-worker 上的 RPC 方法。DM-worker 中的 Server.StartSubTask 方法（dm/worker/server.go）响应来自 DM-master 的 RPC 请求。Server.StartSubTask 中将任务管理请求转发给 Worker.StartSubTask（dm/worker/worker.go），并将处理结果通过 RPC 返回给 DM-master。DM-master 将 DM-worker 返回的 RPC 响应重新封装后通过 RPC 返回给 dmctl。dmctl 通过 common.PrettyPrintResponse 输出命令操作的 RPC 响应。小结在本篇文章中，我们主要介绍了 DM 的各个组件的入口函数，最后以 dmctl 的 start-task 为例介绍了交互的调用流程细节。下一篇文章我们会开始介绍 DM-worker 组件内各数据同步处理单元（relay-unit, dump-unit, load-unit, sync-unit）的设计原理与具体实现。 ...

背景在系统的快速迭代过程中，业务系统往往部署在同一个物理库，没有做核心数据和非核心数据的物理隔离。随着数据量的扩大这种情况会带来稳定性的风险，如库的慢sql，磁盘，IO等等都会相互整体影响，从而影响核心系统的业务稳定性，因此需要将核心业务的业务表从原有库里抽取出来，单独到新库里。而核心数据的迁移，涉及到的一个关键难点：如何平稳及用户无感知的迁移数据，本文将结合闲鱼商品库迁移实践，向大家展示如何解决这个难题的.闲鱼商品数据现状闲鱼商品数据量XX亿级别以上，采用分表分库和读写分离的MYSQL数据库集群来支撑线上查询服务,如下图，通过TDDL[1]数据库中间件进行高效统一管理。可能有些同学会对分表分库相关概念不了解，这里先简单做些介绍。01分表分库原理本质是数据库的水平拆分问题，把一个数据库切分成多个部分放到不同的数据库(server)上，从而缓解单一数据库的性能问题，下图描述分表分库的核心原理：当然分表分库也有负面影响，就是表结构变更及相关管理相比单表麻烦，有一定风险，具体如何决择，还是要根据实际情况来分析。02分表分库下全局Sequence生成分表分库解决在线服务容量和性能问题，但是也带来使用上的复杂度提升。灵活的配置路由规则和路由数据并提供简单易用的封装都是要考虑的，以便业务对此无感知。阿里开源中间件产品TDDL提供了解决方案，对应阿里云上产品为：DRDS[2]。TDDL关键原理不多做介绍，但是在数据库迁移过程中主键冲突风险是故障重要风险点，这里简要介绍下TDDL的全局唯一主键生成原理。如上图，TDDL Sequence是基于数据库更新＋内存分配：每次操作批量分配id，分配id的数量就是sequence的内步长，而原有id值就加上外部长值，后续的分配直接就在内存里拿，这样的优势：简单高效 缺点：无法保证自增顺序。另外数据迁移过程中，在新库中，为了保证跟原数据库主键非冲突，需要设置一个跃迁比较大的主键，防止出现两个库中的主键冲突，这是后续迁移中要注意的关键点之一。数据迁移方案通过前文的简单介绍，大家对闲鱼商品库现状有了初步了解，下面将给大家介绍一下闲鱼是如何做到稳定迁移商品库的。01核心思路数据迁移核心思路抽象起来其实很简单，即如何稳定平滑迁移数据，如下图所示:但围绕这个过程细化下去，我们会遇到不少问题，如：1、数据我们该如何迁移，是一次性？还是分阶段？2、如何校验数据迁移过程的正确性?3、我们业务改造有问题怎么办？如何尽早发现？如何回滚？4、我们的新库性能如何？带着这些问题，我们进一下细化梳理迁移方案。02实现方案如上图所示，整个方案分为几个部份：1、系统改造，包括SQL改造，双写开关，新库sequence创建。SQL改造：加载两套TDDL数据源，一套是给老库的，一套是给新库的，并且生成两套mybatis sql 模板。双写开关：设置好写新库，写老库的开关，用于线上迁移过程中双写过程及遇到问题及时回滚。sequence创建：迁移sequence表时，需要抬升新库的sequence表中的值，用于防止主键冲突，并且需要按照主键消耗量评估一个安全值，这是非常重要的一个细节，再次强调一下。2、稳定性保障，迁库是大事，改造过程中，稳定性重中之重，主要有系统压测，线上流量回放，故障演练。系统压测：主要针对新库进行性能测，防止新库有意外情况。线上流量回放：Edsger W. Dijkstra说过如果调试程序是一种标准的可以铲除BUG的流程，那么，编程就是把他们放进来的流程。通过引入线上数据在测试环境回放，可以尽可能的发现问题，保证改造后的稳定性。故障演练：通过注入一些人为故障，如写新库失败，新库逻辑有问题，及时的演练回滚策略。3、数据迁移，主要利用阿里云数据传输服务DTS[3]的数据迁移能力，涉及到全量迁移、增量迁移、一致性校验及反向任务。全量迁移:数据迁移首要目标如何将历史全量数据迁移到新库中，我们的做法是指定一个时间点，再根据这个时间点查找每张源表的最大及最小id,然后分别批量导到目标库中，如图：整个过程都是查询在线库的备库，因此不影响在线业务的数据库服务。增量迁移:由于迁移过程中业务服务一直运行，因此全量迁移完全成，并且要将全量时间点后的数据追回来，这里核心原理是同步全量时间位点后binlog日志数据来保证数据一致性，需要注意的是增量时间需要前移一小断时间(如5分钟)，其主要原因是全量迁移启动的那刻会有时间差，需要增量前移来保证数据最终一致性，如下图:一致性校验：通过全量及增量的迁移后，此时源库跟目标的数据理论上是一致的,但实际上应用在经过功能测试，线上流量回放等阶段，数据在这个过程中有可能会现不一致的情况,因此正式上线前，需要做数据一致性校验，其原理是分批查询源表(跟全量迁移的查询方式类似)，再跟目标库进行比对,如图所示：反向任务：迁移到新库后，会有一线离线业务对老库还有依赖，需要建立从新库到老库的回流任务，原理跟增量迁移一样，只是变更一下原库及目标库。03迁库流程到这里大家应该对迁库所涉及到点比较清楚了，但还有一个非常重要的事，即梳理整个迁库步骤非常关键，通常会有两种方案。方案一：1、DTS数据追平，即全量同步完成，开启增量同步，并且延迟在秒级以内。2、上线前校验，主要有线上流量回放、压测、一致性校验，故障演练。3、线上开双写，线上同时写新库及老库，这时需要关闭增量同步任务，防止无效覆盖。4、线上校验，执行预先准备的测试脚本并结合一致性校验工具，同时将读流量慢慢切到新库，验证双写逻辑。5、切换数据源，关闭双写并正式写入新库。6、创建反向任务，数据回流老库。方案二：1、DTS数据追平，即全量同步完成，开启增量同步，并且延迟在秒级以内。2、上线前校验，主要有线上流量回放、压测、一致性校验，故障演练。3、线上切开关，写新库， 同时需要关闭增量同步任务，防止无效覆盖。4、创建反向任务，数据回流老库。方案优缺点对比：总结起来方案1迁移流程相对复杂，对迁移的控制力度更细，适合业务复杂，底层改造比较多，想精细化控制迁移步骤的场景，方案2迁移相对简单，过程快速，适合业务流程相对简单，可控，想快速切换的场景，具体选选择哪个方案，同学们可以根据自身的业务情况做选择。这里考虑到闲鱼商品业务复杂，底层改造较多，从稳定性的角度考虑，最终选择方案1。方案1，最关键的是3、4、5步骤，因此需要预先做好回滚计划。04回滚方案回滚方案总原则是不丢数据。最有可能的发生点是双写期间新库出问题，导致线上服务异常，这时只要立即关闭写新库即可，另外就是切到新库后，新库出问题了(如性能问题)，可以立即切回到老库，并通过反向任务，保持数据一致性，最后若没启用分布式事务,双写的时间越短越好,有可能会有数据不一致情况。小结通过周密的迁移方案设计，以及DTS强大的数据迁移工具的能力，闲鱼商品库顺利完成XX亿在线数据库服务迁移，独立的物理部署显著提升商品库在线服务的稳定性。然而不同业务系统的数据库情况可能会有差异，如单库向多库迁移，单表向多表迁移等，不过整体方案大致类似，希望本文迁库实践方案能给大家提供一个可行的参考。本文作者：看松阅读原文本文来自云栖社区合作伙伴“闲鱼技术”，如需转载请联系原作者。

NoSQL最早起源于1998年，但从2009年开始，NoSQL真正开始逐渐兴起和发展。回望历史应该说NoSQL数据库的兴起，完全是十年来伴随互联网技术，大数据数据的兴起和发展，NoSQL在面临大数据场景下相对于关系型数据库运用，这一概念无疑是一种全新思维的注入。接下来本文重点梳理下NoSQL领域最新发展趋势以及阿里云NoSQL最新现状，以飨读者。云NoSQL数据库成为数据库领域重要增长引擎云化趋势不可避免，根据Gartner的报告，2017年超过73%的DBMS增长来自云厂商，Gartner象限里面AWS在领导者象限上升趋势明确，老牌厂商下滑严重。在2018年Gartner报告中，阿里云数据库更是中国唯一首次入围远见者象限。而在众多云厂商里面增长最快的又是NoSQL数据库，云NoSQL成为数据库领域重要增长引擎。阿里云覆盖了主流的NoSQL引擎阿里云集团是国内最早提出数据战略，本身也拥有最大体量的数据，是最早投入NoSQL数据库技术研发，目前也拥有国内最大的专家团队。在持续十年技术加持下，阿里云NoSQL目前覆盖了所有主流的NoSQL数据库，如Redis/mongodb/HBase/图等等。下表是目前阿里云目前覆盖的主流的NoSQL数据库。NoSQL数据库存储类型典型场景Redis/MemcacheKey/Value缓存，搭配所有数据库使用；直播、视频等各种在线场景。MongoDB文档非常适合游戏、地图、基于位置的数据查询等等场景。HBase Wide Column风控、画像、用户行为数据，用户详单，对象存储等等。ElasticSearch/Solr倒排索引文本模糊查询JanusGraph/GDB图关系分析和挖掘，金融、风控阿里云NoSQL数据库多项独家关键技术领先竞争对手，是国内当之无愧的NoSQL数据库排头兵。拥有业界最全的产品的形态以Redis为例，全系覆盖全系列支持2.X, 3.X 4.X, 支持从适合开发者的单节点到多中心的各种产品形态，架构任意变换, 自动容灾, 全面监控。通过各种产品形态，阿里云有能力服务从开发者、中小企业、大企业各种客户，满足不同客户对性价比，SLA，可靠性，管控的各种需求。在最新版本跟进上，阿里云NoSQL也一直在走云厂商前列，18年6月6日全球首发HBase 2.0，同年10月份又全球第一家云厂商支持MongoDB 4.0版本。另外预告一下，这个月我们会推出全新redis 5.0版本，满足众多企业对新版本的诉求，敬请期待！把数据可靠性作为重中之重对大多数公司来说数据的安全性以及可靠性是非常重要的，如何保障数据的安全以及数据的可靠是大多数数据库必须考虑的。2016 IDC的报告表示数据的备份（data-protection）和数据恢复（retention）是NoSQL的最基础的需求之一，阿里云NoSQL数据库也一直把怎么保障客户的数据安全放在首位。以云HBase为例，传统数据库备份恢复的能力都是TB级别，在交易等场景下面是足够的，但面向大数据场景就捉襟见肘了。云HBase通过垂直整合高压缩、内核级优化等能力，将备份恢复的量级成功推高百倍以上，做到 百TB级别甚至更高 ，让客户在大数据量场景下也无后顾之忧。云HBase支持全量（备份集）备份、全量（备份集）恢复、增量（实时）备份、增量（时间点）恢复完整备份恢复能力。全球分布式能力助力企业解决业务出海、地域级灾备、全球同服/多活、跨域数据迁移等关键业务云厂商之所以有这么强大的活力，除了在数据库内核本身长足的进步之外，结合云服务整体生态的创新是重要的一环。阿里云NoSQL数据库持续发力和覆盖了全球分布式能力，助力企业参与全球业务竞争。是否具备全球扩展和分布式的能力，是云NoSQL数据库重要的入门门槛。以Redis为例，我们再18年8月份全球云厂商首家推出Redis全球多活，解决多媒体、游戏、电商等多行业客户业务出海、地域级灾备、全球同服/多活、跨域数据迁移的诉求。多项关键能力独步领域内：全球多活：内核级别支持，实现多节点全球容灾。高可用：同步通道支持断点续传，容忍天级别的隔断，子实例HA自动切换
高性能：单通道10万TPS，高于Redis处理速度；延迟低、洲际内百毫秒延迟
支持数据最终一致性：CRDT冲突解决方案+数据一致性检测，基于Redis内核改造，原生Redis内核无此功能。融合多模和多负载能力，提供一站式低成本数据处理平台2018年12月13日第8届中国云计算标准和应用大会隆重发布X-Pack，在云HBase基础上新增多模型和多负载支持。
多模型支持：同时支持KV、时序、时空、图、文档等多种数据模型，内置丰富处理能力，让业务开发效率提升百倍。多负载支持：ApsaraDB HBase在在线能力的基础上，融合流处理、批处理、OLAP，OLTP、高速对象存储，全文检索等能力，提供客户业务开箱即用的能力。通过多模型和多负载的支持，基于Apache HBase及HBase生态构建的 低成本、一站式 数据处理平台，支持Spark、二级索引、全文查询、图、时序、时空、分析等能力，是物联网、风控推荐、对象存储、AI、Feeds等场景首选数据库。多项独家企业级能力，领域内领先，不负重托客户选择NoSQL数据库服务，一个非常看重的关键点是就是企业级能力，解决企业生产开发过程中，管理，维护各个方案的瓶颈。NoSQL数据库服务深度结合企业应用场景，经过长期的发展，目前具备了多项独家企业级能力，以MongoDB为例：跨域双活：数据双向同步，相比现有通道产品提升100%效率，业界领先。首创物理+逻辑备份双能力：物理备份，相比开源版本备份效率提升100%，恢复效率提升300%。创新性提供逻辑snapshot能力，解决政企等定期大批量数据更新需求，同架构下性价比提升100%。秒级监控及智能诊断能力：提供每秒粒度的监控数据采集，监控精度提升数十倍。结合监控、审计等数据提供智能诊断，分析系统运行瓶颈并自动化提供优化建议。下面是云MongoDB和自建的社区版本的一个对比，云服务再搭建、安全、优化、运维、定制等各个方面全面胜出，全面降低客户的TCO。即将重磅发布CloudNative图数据库随着企业的数据越来越多，业务越来越复杂，客户提出了很多实时在线的高性能图数据存储和查询服务的诉求。我们也将再本月重磅发布阿里云首款Cloud Native专业的图数据库。新的图数据库将会支持丰富的能力，并在易用性，高可用站上一个新的高度，非常适合拥有社交网络、金融欺诈检测、实时推荐引擎、知识图谱、网络/IT运营方面诉求的客户。展望未来，阿里云NoSQL数据库也会持续围绕客户业务，成本，运维各个方面进行优化和创新，成就客户，争做最好的NoSQL数据库而持续努力！最后，阿里即将召开2019阿里云峰会 北京站有专门的数据库专场《数据库专场：云时代的企业级数据库架构与实践》，进一步分享数据库的最新发展趋势，欢迎大家报名：
https://www.yunqi.org/goPage?page=bj_signup_mb&activeId=2&ticketTypeId=39&channelId=12本文作者：所在jason阅读原文本文为云栖社区原创内容，未经允许不得转载。

概述七牛云OSS对象存储bucket创建后有一个「外链默认域名」这个域名, 如果没有记错的2018上半年没有回收这个概念, 2018下半年隐隐约约记录收到过「【七牛云】测试域名回收通知」邮件, 出现这个域名后也没有太在意, 因为是个人使用, 怎么着都成! 后来用得着静态文件存储时就接着新建bucket, 接二连三的收到「测试域名回收通知」回收后最大的影响就是「整个Bucket基本所有功能都不能使用了, 都不能使用了, 都不能使用了~」下载什么的你就可劲点吧, 额~~~, 好吧！所有外部引用文件都不可用了, 你之前的所有引用又都想使用之前那些文件吧, 好了, 下载下来这个文件将其上传到阿里云对象存储OSS完美解决问题, 请看下面迁移过程, 可能会对你有所帮助~建立一个同区下的新Bucket您需要先新建一个同区域存储空间，会分配一个新的测试域名到新空间下载qshell关于qshell的下载请移步Github, 关于qshell的配置请参考命令行工具(qshell), 最好将qshell添加系统环境变量设置qshell登录账号查看 qshell account 命令使用方式➜ qshell account –helpGet/Set AccessKey and SecretKeyUsage: qshell account [<AccessKey> <SecretKey> <Name>] [flags]Flags: -h, –help help for account -w, –overwrite overwrite account or not when account exists in local db, by default not overwriteGlobal Flags: -C, –config string config file (default is $HOME/.qshell.json) -d, –debug debug mode -L, –local use current directory as config file path -v, –version show version添加 qshell account 登录账号AccessKey: 访问密钥SecretKey: 安全密钥SelfCustomName: 此处填写自定义的用户名(这个name就是qshell存存您登陆的账户名，可以随便设置的，比如qiniuaccount 或者 account_1 等等)AccessKey 及 SecretKey 可以到控制台右上角的个人面板，密钥管理里找到### 格式: qshell account AccessKey SecretKey SelfCustomName### 列如:➜ qshell account AccessKey SecretKey warnerwu将已被回收Bucket文件同步到新建Bucket下载已被回收Bucket下所有文件列表到文件进入到「本地数据备份路径」如➜ cd /qiniu/migration执行以下命令, 下载已被回收Bucket下所有文件列表到文件➜ migration qshell listbucket warner -o warner-data-list.txt下载到已被回收Bucket下所有文件列表到文件具体内容类似如下图所示将下载到的文件的第一列复制到一个最终文件列表文件➜ migration cat warner-data-list.txt | awk ‘{print $1}’ > warner-data-list-final.txt文件列表到文件内容如下:将文件列表文件将旧Bucket文件列表文件拷贝到新建Bucket文件列表➜ migration qshell batchcopy warner warnerwu-migration -i warner-data-list-final.txt执行以上命令七牛云会有一个安全机制就是让你输入验证码到此文件也就会从旧Bucket拷贝或者说同步到新建Bucket列表啦下载已同步到建新Bucket文件到本地备份文件夹关于如何下更详细讲解可以移步Github下载说明文档添加一个下载配置文件文件名如 warnerwu-migration-download.confdest_dir: 为本地备份文件绝对路径文件夹, 不过这个绝对路径要提交建立好bucket: 要下载Bucket下文件所在的Bucket名称{ “dest_dir” : “/Users/warnerwu/qiniu/migration/warnerwu-migraition”, “bucket” : “warnerwu-migration”}下载Bucket列表文件到本地备份文件夹-c: 10 参数 -c 代表是要使用多个 goroutine 进行下载Bucket列表下的文件, 我们都知道七牛后端全站 Go 语言开发, 对头, 你当前使用的 qshell 也是使用 Go 语言编写➜ migration qshell qdownload -c 10 warnerwu-migration-download.conf下载完成后会生成一个下载日志文件, 它是默认生成当前用户家目录下查看下载日志文件tail 默认显示最后10行tail -n 24 可以指定显示行数➜ migration tail /Users/warnerwu/.qshell/qdownload/e65c69a164299e2f7045ea3b7a3d18d7/e65c69a164299e2f7045ea3b7a3d18d7.log2019/02/18 22:14:33.548 [I] Download 2017.02.17.attrbute.01.png => /Users/warnerwu/qiniu/migration/warnerwu-migraition/2017.02.17.attrbute.01.png success 1785.53KB/s2019/02/18 22:14:33.548 [I] ——-Download Result——-2019/02/18 22:14:33.548 [I] Total: 262019/02/18 22:14:33.548 [I] Skipped: 02019/02/18 22:14:33.548 [I] Exists: 02019/02/18 22:14:33.548 [I] Success: 262019/02/18 22:14:33.548 [I] Update: 02019/02/18 22:14:33.548 [I] Failure: 02019/02/18 22:14:33.548 [I] Duration: 2.205420428s2019/02/18 22:14:33.548 [I] —————————–可以看到这个下载还是很快的只用了 2 秒左右的时间, 并且所有的下载都成功了！查看下载文件最后你可以将文件上传到阿里云对象存储OSS上, 它不存在「测试域名」的问题, 不过你要先购买对象存储OSS, 不贵40G好像是9块多钱的样子并且是一年!希望本文对你的工作和学习有所帮助如果觉得还不错怎么感谢我呢？ 妈呀! 点赞啊!Good Luck! from warnerwu at 2019.02.18 PM ...

作者：张学程简介TiDB-DM（Data Migration）是用于将数据从 MySQL/MariaDB 迁移到 TiDB 的工具。该工具既支持以全量备份文件的方式将 MySQL/MariaDB 的数据导入到 TiDB，也支持通过解析执行 MySQL/MariaDB binlog 的方式将数据增量同步到 TiDB。特别地，对于有多个 MySQL/MariaDB 实例的分库分表需要合并后同步到同一个 TiDB 集群的场景，DM 提供了良好的支持。如果你需要从 MySQL/MariaDB 迁移到 TiDB，或者需要将 TiDB 作为 MySQL/MariaDB 的从库，DM 将是一个非常好的选择。架构设计DM 是集群模式的，其主要由 DM-master、DM-worker 与 DM-ctl 三个组件组成，能够以多对多的方式将多个上游 MySQL 实例的数据同步到多个下游 TiDB 集群，其架构图如下：DM-master：管理整个 DM 集群，维护集群的拓扑信息，监控各个 DM-worker 实例的运行状态；进行数据同步任务的拆解与分发，监控数据同步任务的执行状态；在进行合库合表的增量数据同步时，协调各 DM-worker 上 DDL 的执行或跳过；提供数据同步任务管理的统一入口。DM-worker：与上游 MySQL 实例一一对应，执行具体的全量、增量数据同步任务；将上游 MySQL 的 binlog 拉取到本地并持久化保存；根据定义的数据同步任务，将上游 MySQL 数据全量导出成 SQL 文件后导入到下游 TiDB，或解析本地持久化的 binlog 后增量同步到下游 TiDB；编排 DM-master 拆解后的数据同步子任务，监控子任务的运行状态。DM-ctl：命令行交互工具，通过连接到 DM-master 后，执行 DM 集群的管理与数据同步任务的管理。实现原理数据迁移流程单个 DM 集群可以同时运行多个数据同步任务；对于每一个同步任务，可以拆解为多个子任务同时由多个 DM-worker 节点承担，其中每个 DM-worker 节点负责同步来自对应的上游 MySQL 实例的数据。对于单个 DM-worker 节点上的单个数据同步子任务，其数据迁移流程如下，其中上部的数据流向为全量数据迁移、下部的数据流向为增量数据同步：在每个 DM-worker 节点内部，对于特定的数据同步子任务，主要由 dumper、loader、relay 与 syncer（binlog replication）等数据同步处理单元执行具体的数据同步操作。对于全量数据迁移，DM 首先使用 dumper 单元从上游 MySQL 中将表结构与数据导出成 SQL 文件；然后使用 loader 单元读取这些 SQL 文件并同步到下游 TiDB。对于增量数据同步，首先使用 relay 单元作为 slave 连接到上游 MySQL 并拉取 binlog 数据后作为 relay log 持久化存储在本地，然后使用 syncer 单元读取这些 relay log 并解析构造成 SQL 语句后同步到下游 TiDB。这个增量同步的过程与 MySQL 的主从复制类似，主要区别在于在 DM 中，本地持久化的 relay log 可以同时供多个不同子任务的 syncer 单元所共用，避免了多个任务需要重复从上游 MySQL 拉取 binlog 的问题。数据迁移并发模型为加快数据导入速度，在 DM 中不论是全量数据迁移，还是增量数据同步，都在其中部分阶段使用了并发处理。对于全量数据迁移，在导出阶段，dumper 单元调用 mydumper 导出工具执行实际的数据导出操作，对应的并发模型可以直接参考 mydumper 的源码。在使用 loader 单元执行的导入阶段，对应的并发模型结构如下：使用 mydumper 执行导出时，可以通过 –chunk-filesize 等参数将单个表拆分成多个 SQL 文件，这些 SQL 文件对应的都是上游 MySQL 某一个时刻的静态快照数据，且各 SQL 文件间的数据不存在关联。因此，在使用 loader 单元执行导入时，可以直接在一个 loader 单元内启动多个 worker 工作协程，由各 worker 协程并发、独立地每次读取一个待导入的 SQL 文件进行导入。即 loader 导入阶段，是以 SQL 文件级别粒度并发进行的。在 DM 的任务配置中，对于 loader 单元，其中的 pool-size 参数即用于控制此处 worker 协程数量。对于增量数据同步，在从上游拉取 binlog 并持久化到本地的阶段，由于上游 MySQL 上 binlog 的产生与发送是以 stream 形式进行的，因此这部分只能串行处理。在使用 syncer 单元执行的导入阶段，在一定的限制条件下，可以执行并发导入，对应的模型结构如下：当 syncer 读取与解析本地 relay log 时，与从上游拉取 binlog 类似，是以 stream 形式进行的，因此也只能串行处理。当 syncer 解析出各 binlog event 并构造成待同步的 job 后，则可以根据对应行数据的主键、索引等信息经过 hash 计算后分发到多个不同的待同步 job channel 中；在 channel 的另一端，与各个 channel 对应的 worker 协程并发地从 channel 中取出 job 后同步到下游的 TiDB。即 syncer 导入阶段，是以 binlog event 级别粒度并发进行的。在 DM 的任务配置中，对于 syncer 单元，其中的 worker-count 参数即用于控制此处 worker 协程数量。但 syncer 并发同步到下游 TiDB 时，存在一些限制，主要包括：对于 DDL，由于会变更下游的表结构，因此必须确保在旧表结构对应的 DML 都同步完成后，才能进行同步。在 DM 中，当解析 binlog event 得到 DDL 后，会向每一个 job channel 发送一个特殊的 flush job；当各 worker 协程遇到 flush job 时，会立刻向下游 TiDB 同步之前已经取出的所有 job；等各 job channel 中的 job 都同步到下游 TiDB 后，开始同步 DDL；等待 DDL 同步完成后，继续同步后续的 DML。即 DDL 不能与 DML 并发同步，且 DDL 之前与之后的 DML 也不能并发同步。sharding 场景下 DDL 的同步处理见后文。对于 DML，多条 DML 可能会修改同一行的数据，甚至是主键。如果并发地同步这些 DML，则可能造成同步后数据的不一致。DM 中对于 DML 之间的冲突检测与处理，与 TiDB-Binlog 中的处理类似，具体原理可以阅读《TiDB EcoSystem Tools 原理解读（一）TiDB-Binlog 架构演进与实现原理》中关于 Drainer 内 SQL 之间冲突检测的讨论。合库合表数据同步在使用 MySQL 支撑大量数据时，经常会选择使用分库分表的方案。但当将数据同步到 TiDB 后，通常希望逻辑上进行合库合表。DM 为支持合库合表的数据同步，主要实现了以下的一些功能。table router为说明 DM 中 table router（表名路由）功能，先看如下图所示的一个例子：在这个例子中，上游有 2 个 MySQL 实例，每个实例有 2 个逻辑库，每个库有 2 个表，总共 8 个表。当同步到下游 TiDB 后，希望所有的这 8 个表最终都合并同步到同一个表中。但为了能将 8 个来自不同实例、不同库且有不同名的表同步到同一个表中，首先要处理的，就是要能根据某些定义好的规则，将来自不同表的数据都路由到下游的同一个表中。在 DM 中，这类规则叫做 router-rules。对于上面的示例，其规则如下：name-of-router-rule: schema-pattern: “schema_” table-pattern: “table_” target-schema: “schema” target-table: “table"name-of-router-rule：规则名，用户指定。当有多个上游实例需要使用相同的规则时，可以只定义一条规则，多个不同的实例通过规则名进行引用。schema-pattern：用于匹配上游库（schema）名的模式，支持在尾部使用通配符（）。这里使用 schema_ 即可匹配到示例中的两个库名。table-pattern：用于匹配上游表名的模式，与 schema-pattern 类似。这里使用 table_* 即可匹配到示例中的两个表名。target-schema：目标库名。对于库名、表名匹配的数据，将被路由到这个库中。target-table：目标表名。对于库名、表名匹配的数据，将被路由到 target-schema 库下的这个表中。在 DM 内部实现上，首先根据 schema-pattern / table-pattern 构造对应的 trie 结构，并将规则存储在 trie 节点中；当有 SQL 需要同步到下游时，通过使用上游库名、表名查询 trie 即可得到对应的规则，并根据规则替换原 SQL 中的库名、表名；通过向下游 TiDB 执行替换后的 SQL 即完成了根据表名的路由同步。有关 router-rules 规则的具体实现，可以阅读 TiDB-Tools 下的 table-router pkg 源代码。column mapping有了 table router 功能，已经可以完成基本的合库合表数据同步了。但在数据库中，我们经常会使用自增类型的列作为主键。如果多个上游分表的主键各自独立地自增，将它们合并同步到下游后，就很可能会出现主键冲突，造成数据的不一致。我们可看一个如下的例子：在这个例子中，上游 4 个需要合并同步到下游的表中，都存在 id 列值为 1 的记录。假设这个 id 列是表的主键。在同步到下游的过程中，由于相关更新操作是以 id 列作为条件来确定需要更新的记录，因此会造成后同步的数据覆盖前面已经同步过的数据，导致部分数据的丢失。在 DM 中，我们通过 column mapping 功能在数据同步的过程中依据指定规则对相关列的数据进行转换改写来避免数据冲突与丢失。对于上面的示例，其中 MySQL 实例 1 的 column mapping 规则如下：mapping-rule-of-instance-1: schema-pattern: “schema_” table-pattern: “table_” expression: “partition id” source-column: “id” target-column: “id” arguments: [“1”, “schema_”, “table_”] mapping-rule-of-instance-1：规则名，用户指定。由于不同的上游 MySQL 实例需要转换得到不同的值，因此通常每个 MySQL 实例使用一条专有的规则。schema-pattern / table-pattern：上游库名、表名匹配模式，与 router-rules 中的对应配置项一致。expression：进行数据转换的表达式名。目前常用的表达式即为 “partition id”，有关该表达式的具体说明见下文。source-column：转换表达式的输入数据对应的来源列名，“id” 表示这个表达式将作用于表中名为 id 的列。暂时只支持对单个来源列进行数据转换。target-column：转换表达式的输出数据对应的目标列名，与 source-column 类似。暂时只支持对单个目标列进行数据转换，且对应的目标列必须已经存在。arguments：转换表达式所依赖的参数。参数个数与含义依具体表达式而定。partition id 是目前主要受支持的转换表达式，其通过为 bigint 类型的值增加二进制前缀来解决来自不同表的数据合并同步后可能产生冲突的问题。partition id 的 arguments 包括 3 个参数，分别为：MySQL 实例 ID：标识数据的来源 MySQL 实例，用户自由指定。如 “1” 表示匹配该规则的数据来自于 MySQL 实例 1，且这个标识将被转换成数值后以二进制的形式作为前缀的一部分添加到转换后的值中。库名前缀：标识数据的来源逻辑库。如 “schema_” 应用于 schema_2 逻辑库时，表示去除前缀后剩下的部分（数字 2）将以二进制的形式作为前缀的一部分添加到转换后的值中。表名前缀：标识数据的来源表。如 “table_” 应用于 table_3 表时，表示去除前缀后剩下的部分（数字 3）将以二进制的形式作为前缀的一部分添加到转换后的值中。各部分在经过转换后的数值中的二进制分布如下图所示（各部分默认所占用的 bits 位数如图所示）：假如转换前的原始数据为 123，且有如上的 arguments 参数设置，则转换后的值为：1<<(64-1-4) | 2<<(64-1-4-7) | 3<<(64-1-4-7-8) | 123另外，arguments 中的 3 个参数均可设置为空字符串（""），即表示该部分不被添加到转换后的值中，且不占用额外的 bits。比如将其设置为[“1”, “”, “table_"]，则转换后的值为：1 << (64-1-4) | 3<< (64-1-4-8) | 123有关 column mapping 功能的具体实现，可以阅读 TiDB-Tools 下的 column-mapping pkg 源代码。sharding DDL有了 table router 和 column mapping 功能，DML 的合库合表数据同步已经可以正常进行了。但如果在增量数据同步的过程中，上游待合并的分表上执行了 DDL 操作，则可能出现问题。我们先来看一个简化后的在分表上执行 DDL 的例子。在上图的例子中，分表的合库合表简化成了上游只有两个 MySQL 实例，每个实例内只有一个表。假设在开始数据同步时，将两个分表的表结构 schema 的版本记为 schema V1，将 DDL 执行完成后的表结构 schema 的版本记为 schema V2。现在，假设数据同步过程中，从两个上游分表收到的 binlog 数据有如下的时序：开始同步时，从两个分表收到的都是 schema V1 的 DML。在 t1 时刻，收到实例 1 上分表的 DDL。从 t2 时刻开始，从实例 1 收到的是 schema V2 的 DML；但从实例 2 收到的仍是 schema V1 的 DML。在 t3 时刻，收到实例 2 上分表的 DDL。从 t4 时刻开始，从实例 2 收到的也是 schema V2 的 DML。假设在数据同步过程中，不对分表的 DDL 进行处理。当将实例 1 的 DDL 同步到下游后，下游的表结构会变更成为 schema V2。但对于实例 2，在 t2 时刻到 t3 时刻这段时间内收到的仍然是 schema V1 的 DML。当尝试把这些与 schema V1 对应的 DML 同步到下游时，就会由于 DML 与表结构的不一致而发生错误，造成数据无法正确同步。继续使用上面的例子，来看看我们在 DM 中是如何处理合库合表过程中的 DDL 同步的。在这个例子中，DM-worker-1 用于同步来自 MySQL 实例 1 的数据，DM-worker-2 用于同步来自 MySQL 实例 2 的数据，DM-master 用于协调多个 DM-worker 间的 DDL 同步。从 DM-worker-1 收到 DDL 开始，简化后的 DDL 同步流程为：DM-worker-1 在 t1 时刻收到来自 MySQL 实例 1 的 DDL，自身暂停该 DDL 对应任务的 DDL 及 DML 数据同步，并将 DDL 相关信息发送给 DM-master。DM-master 根据 DDL 信息判断需要协调该 DDL 的同步，为该 DDL 创建一个锁，并将 DDL 锁信息发回给 DM-worker-1，同时将 DM-worker-1 标记为这个锁的 owner。DM-worker-2 继续进行 DML 的同步，直到在 t3 时刻收到来自 MySQL 实例 2 的 DDL，自身暂停该 DDL 对应任务的数据同步，并将 DDL 相关信息发送给 DM-master。DM-master 根据 DDL 信息判断该 DDL 对应的锁信息已经存在，直接将对应锁信息发回给 DM-worker-2。DM-master 根据启动任务时的配置信息、上游 MySQL 实例分表信息、部署拓扑信息等，判断得知已经收到了需要合表的所有上游分表的该 DDL，请求 DDL 锁的 owner（DM-worker-1）向下游同步执行该 DDL。DM-worker-1 根据 step 2 时收到的 DDL 锁信息验证 DDL 执行请求；向下游执行 DDL，并将执行结果反馈给 DM-master；若执行 DDL 成功，则自身开始继续同步后续的（从 t2 时刻对应的 binlog 开始的）DML。DM-master 收到来自 owner 执行 DDL 成功的响应，请求在等待该 DDL 锁的所有其他 DM-worker（DM-worker-2）忽略该 DDL，直接继续同步后续的（从 t4 时刻对应的 binlog 开始的）DML。根据上面 DM 处理多个 DM-worker 间的 DDL 同步的流程，归纳一下 DM 内处理多个 DM-worker 间 sharding DDL 同步的特点：根据任务配置与 DM 集群部署拓扑信息，在 DM-master 内建立一个需要协调 DDL 同步的逻辑 sharding group，group 中的成员为处理该任务拆解后各子任务的 DM-worker。各 DM-worker 在从 binlog event 中获取到 DDL 后，会将 DDL 信息发送给 DM-master。DM-master 根据来自 DM-worker 的 DDL 信息及 sharding group 信息创建/更新 DDL 锁。如果 sharding group 的所有成员都收到了某一条 DDL，则表明上游分表在该 DDL 执行前的 DML 都已经同步完成，可以执行 DDL，并继续后续的 DML 同步。上游分表的 DDL 在经过 table router 转换后，对应需要在下游执行的 DDL 应该一致，因此仅需 DDL 锁的 owner 执行一次即可，其他 DM-worker 可直接忽略对应的 DDL。从 DM 处理 DM-worker 间 sharding DDL 同步的特点，可以看出该功能存在以下一些限制：上游的分表必须以相同的顺序执行（table router 转换后相同的）DDL，比如表 1 先增加列 a 后再增加列 b，而表 2 先增加列 b 后再增加列 a，这种不同顺序的 DDL 执行方式是不支持的。一个逻辑 sharding group 内的所有 DM-worker 对应的上游分表，都应该执行对应的 DDL，比如其中有 DM-worker-2 对应的上游分表未执行 DDL，则其他已执行 DDL 的 DM-worker 都会暂停同步任务，等待 DM-worker-2 收到对应上游的 DDL。由于已经收到的 DDL 的 DM-worker 会暂停任务以等待其他 DM-worker 收到对应的 DDL，因此数据同步延迟会增加。增量同步开始时，需要合并的所有上游分表结构必须一致，才能确保来自不同分表的 DML 可以同步到一个确定表结构的下游，也才能确保后续各分表的 DDL 能够正确匹配与同步。在上面的示例中，每个 DM-worker 对应的上游 MySQL 实例中只有一个需要进行合并的分表。但在实际场景下，一个 MySQL 实例可能有多个分库内的多个分表需要进行合并，比如前面介绍 table router 与 column mapping 功能时的例子。当一个 MySQL 实例中有多个分表需要合并时，sharding DDL 的协调同步过程增加了更多的复杂性。假设同一个 MySQL 实例中有 table_1 和 table_2 两个分表需要进行合并，如下图：由于数据来自同一个 MySQL 实例，因此所有数据都是从同一个 binlog 流中获得。在这个例子中，时序如下：开始同步时，两个分表收到的数据都是 schema V1 的 DML。在 t1 时刻，收到了 table_1 的 DDL。从 t2 时刻到 t3 时刻，收到的数据同时包含 table_1 schema V2 的 DML 及 table_2 schema V1 的 DML。在 t3 时刻，收到了 table_2 的 DDL。从 t4 时刻开始，两个分表收到的数据都是 schema V2 的 DML。假设在数据同步过程中不对 DDL 进行特殊处理，当 table_1 的 DDL 同步到下游、变更下游表结构后，table_2 schema V1 的 DML 将无法正常同步。因此，在单个 DM-worker 内部，我们也构造了与 DM-master 内类似的逻辑 sharding group，但 group 的成员是同一个上游 MySQL 实例的不同分表。但 DM-worker 内协调处理 sharding group 的同步不能完全与 DM-master 处理时一致，主要原因包括：当收到 table_1 的 DDL 时，同步不能暂停，需要继续解析 binlog 才能获得后续 table_2 的 DDL，即需要从 t2 时刻继续向前解析直到 t3 时刻。在继续解析 t2 时刻到 t3 时刻的 binlog 的过程中，table_1 的 schema V2 的 DML 不能向下游同步；但在 sharding DDL 同步并执行成功后，这些 DML 需要同步到下游。在 DM 中，简化后的 DM-worker 内 sharding DDL 同步流程为：在 t1 时刻收到 table_1 的 DDL，记录 DDL 信息及此时的 binlog 位置点信息。继续向前解析 t2 时刻到 t3 时刻的 binlog。对于属于 table_1 的 schema V2 DML，忽略；对于属于 table_2 的 schema V1 DML，正常同步到下游。在 t3 时刻收到 table_2 的 DDL，记录 DDL 信息及此时的 binlog 位置点信息。根据同步任务配置信息、上游库表信息等，判断该 MySQL 实例上所有分表的 DDL 都已经收到；将 DDL 同步到下游执行、变更下游表结构。设置新的 binlog 流的解析起始位置点为 step 1 时保存的位置点。重新开始解析从 t2 时刻到 t3 时刻的 binlog。对于属于 table_1 的 schema V2 DML，正常同步到下游；对于属于 table_2 的 shema V1 DML，忽略。解析到达 step 4 时保存的 binlog 位置点，可得知在 step 3 时被忽略的所有 DML 都已经重新同步到下游。继续从 t4 时刻对应的 binlog 位置点正常同步。从上面的分析可以知道，DM 在处理 sharding DDL 同步时，主要通过两级 sharding group 来进行协调控制，简化的流程为：各 DM-worker 独立地协调对应上游 MySQL 实例内多个分表组成的 sharding group 的 DDL 同步。当 DM-worker 内所有分表的 DDL 都收到时，向 DM-master 发送 DDL 相关信息。DM-master 根据 DM-worker 发来的 DDL 信息，协调由各 DM-worker 组成的 sharing group 的 DDL 同步。当 DM-master 收到所有 DM-worker 的 DDL 信息时，请求 DDL lock 的 owner（某个 DM-worker）执行 DDL。owner 执行 DDL，并将结果反馈给 DM-master；自身开始重新同步在内部协调 DDL 同步过程中被忽略的 DML。当 DM-master 发现 owner 执行 DDL 成功后，请求其他所有 DM-worker 开始继续同步。其他所有 DM-worker 各自开始重新同步在内部协调 DDL 同步过程中被忽略的 DML。所有 DM-worker 在重新同步完成被忽略的 DML 后，继续正常同步。数据同步过滤在进行数据同步的过程中，有时可能并不需要将上游所有的数据都同步到下游，这时一般期望能在同步过程中根据某些规则，过滤掉部分不期望同步的数据。在 DM 中，支持 2 种不同级别的同步过滤方式。库表黑白名单DM 在 dumper、loader、syncer 三个处理单元中都支持配置规则只同步/不同步部分库或表。对于 dumper 单元，其实际调用 mydumper 来 dump 上游 MySQL 的数据。比如只期望导出 test 库中的 t1、t2 两个表的数据，则可以为 dumper 单元配置如下规则：name-of-dump-rule: extra-args: “-B test -T t1,t2"name-of-dump-rule：规则名，用户指定。当有多个上游实例需要使用相同的规则时，可以只定义一条规则，多个不同的实例通过规则名进行引用。extra-args：dumper 单元额外参数。除 dumper 单元中明确定义的配置项外的其他所有 mydumper 配置项都通过此参数传入，格式与使用 mydumper 时一致。有关 mydumper 对库表黑白名单的支持，可查看 mydumper 的参数及 mydumper 的源码。对于 loader 和 syncer 单元，其对应的库表黑白名单规则为 black-white-list。假设只期望同步 test 库中的 t1、t2 两个表的数据，则可配置如下规则：name-of-bwl-rule: do-tables: - db-name: “test” tbl-name: “t1” - db-name: “test” tbl-name: “t2"示例中只使用了该规则的部分配置项，完整的配置项及各配置项的含义，可阅读该功能对应的用户文档。DM 中该规则与 MySQL 的主从同步过滤规则类似，因此也可参考 Evaluation of Database-Level Replication and Binary Logging Options 与 Evaluation of Table-Level Replication Options。对于 loader 单元，在解析 SQL 文件名获得库名表名后，会与配置的黑白名单规则进行匹配，如果匹配结果为不需要同步，则会忽略对应的整个 SQL 文件。对于 syncer 单元，在解析 binlog 获得库名表名后，会与配置的黑白名单规则进行匹配，如果匹配结果为不需要同步，则会忽略对应的（部分）binlog event 数据。binlog event 过滤在进行增量数据同步时，有时会期望过滤掉某些特定类型的 binlog event，两个典型的场景包括：上游执行 TRUNCATE TABLE 时不希望清空下游表中的数据。上游分表上执行 DROP TABLE 时不希望 DROP 下游合并后的表。在 DM 中支持根据 binlog event 的类型进行过滤，对于需要过滤 TRUNCATE TABLE 与 DROP TABLE 的场景，可配置规则如下：name-of-filter-rule: schema-pattern: “test_” table-pattern: “t_” events: [“truncate table”, “drop table”] action: Ignore规则的匹配模式与 table router、column mapping 类似，具体的配置项可阅读该功能对应的用户文档。在实现上，当解析 binlog event 获得库名、表名及 binlog event 类型后，与配置的规则进行匹配，并在匹配后依据 action 配置项来决定是否需要进行过滤。有关 binlog event 过滤功能的具体实现，可以阅读 TiDB-Tools 下的 binlog-filter pkg 源代码。 ...

运维攻城狮作为最优（ku）秀（bi）的职业若是没有些方法技巧那是极可能需要牺牲些个人时间对此，本萌我不能视而不见，见而不救啊！比如，ES集群里的数据越来越大，日增500G日志数据，日志数量太多怎么办？来来来，掌声有请帮你做一波扩容，让你走上人生巅峰！01节点信息目前集群中的节点信息如下：新增数据节点规格：新增master节点规格：02扩容思路1、将master从集群中分离出来2、重启节点时给集群中老节点标记一个tag：old3、将所有索引设置只分配到带有old标签的节点4、将不怎么使用的索引close5、将新增的data节点加入到集群中，并设置新的tag：new6、修改索引template，新建的索引设置新建到tag为new的节点上。7、在业务低峰期分批将之前在old节点上的索引迁移到new节点上。03实践步骤1、分离master节点查看当前master节点：查看集群中的所有索引，暂时关闭一批历史不需要搜索使用的索引 ps:主要是需要重启节点，open的索引越少，集群恢复的越快！关闭集群reroute：分别修改集群中node001~node006的配置文件，滚动重启：配置好新的master节点es010、es011、es012节点状态：查看个节点tag：重启node005，将集群master转移到专属节点。至此，master节点已经从原有集群中分离，并且集群节点也都已做了标记tag。2、修改索引的配置确保当前集群中的索引只分配到当前标记为old的数据节点，不会分配到新增的数据节点。3、配置新数据节点4、打开集群分配，并分批将数据迁移完成以上四步就可以完成整个数据迁移了“ElasticSearch运维技术”了解一下课件PPT+讲师答疑+沙龙直播学习ElasticSearch在袋鼠云、阿里、滴滴、有赞的实践应用成果；学习ElasticSearch的开发思路和性能优化策略！

背景信息在云计算服务高速发展的今天，如何方便快捷地将已有的服务器系统迁移上云，有着非常重要的意义。阿里云服务器迁移服务方案，即迁移服务，正是在这个需求背景下应运而生。它极大地简化了服务器系统迁移工具的使用条件、降低了使用成本，使用户的系统一键迁移到阿里云成为可能。使用迁移服务来进行系统迁移比较便捷，您可以先参考迁云工具帮助文档了解使用条件及基本操作。迁移流程1、熟悉迁移工具使用方法，提前做好测试演练。2、评估迁移时间/成本，制定迁移计划。3、正式迁移，可咨询阿里云团队支持。数据传输服务DTShttps://www.aliyun.com/produc…数据库和应用迁移 ADAMhttps://www.aliyun.com/produc…闪电立方 Lightning Cubehttps://www.aliyun.com/produc…使用迁云工具迁移服务器至阿里云https://help.aliyun.com/docum…4、创建按量实例，进行系统业务联调。5、切换到云端系统，将实例升级为包年包月。文档合集本地数据迁移至阿里云ECS使用迁云工具迁移服务器至阿里云https://help.aliyun.com/docum…ECS迁移服务—全量迁移https://help.aliyun.com/docum…ECS迁移服务—增量迁移https://help.aliyun.com/docum…ECS迁移服务—批量迁移https://help.aliyun.com/docum…ECS迁移服务—迁移到目标实例https://help.aliyun.com/docum…ECS迁移服务—其他迁移场景https://help.aliyun.com/docum…ECS迁移服务—VPC内网迁移https://help.aliyun.com/docum…NAT Gateway自建SNAT网关平滑迁移到NAT网关https://help.aliyun.com/docum…在线迁移服务HTTP/HTTPS源迁移教程https://help.aliyun.com/docum…RDS使用SSMS和BCP迁移SQL Server数据库https://help.aliyun.com/docum…使用 DTS 迁移 MySQL 数据https://help.aliyun.com/docum…使用 mysqldump 迁移 MySQL 数据https://help.aliyun.com/docum…全量备份数据上云SQL Server 2008 R2版https://help.aliyun.com/docum…使用 DTS 迁移 SQL Server 数据https://help.aliyun.com/docum…SQL Server 不停机迁移https://help.aliyun.com/docum…将本地 PostgreSQL 迁移至 RDS for PostgreSQLhttps://help.aliyun.com/docum…使用 psql 命令迁移 PostgreSQL 数据https://help.aliyun.com/docum…Oracle到PPAS不停机数据迁移https://help.aliyun.com/docum…RedisRedis集群迁移https://help.aliyun.com/docum…使用DTS进行迁移https://help.aliyun.com/docum…Codis 集群迁移https://help.aliyun.com/docum…使用RDB文件进行迁移https://help.aliyun.com/docum…使用AOF文件进行迁移https://help.aliyun.com/docum…使用redis-port进行迁移https://help.aliyun.com/docum…MaxComputeHadoop数据迁移MaxComputehttps://help.aliyun.com/docum…JSON数据从OSS迁移到MaxCompute最佳实践https://help.aliyun.com/docum…JSON数据从MongoDB迁移到MaxCompute最佳实践https://help.aliyun.com/docum…RDS迁移到Maxcompute实现动态分区最佳实践https://help.aliyun.com/docum…Elasticsearch自建ES迁移https://help.aliyun.com/knowl…logstash部署https://help.aliyun.com/docum…E-MapReduceE-MapReduce数据迁移方案https://help.aliyun.com/docum…云解析DNS迁移通用方案https://help.aliyun.com/docum…AnalyticDB使用kettle将本地数据导入分析型数据库https://help.aliyun.com/docum…数据库和应用迁移服务 ADAM传统 IT 系统上云 + 云上 IT 系统迁移https://help.aliyun.com/produ…更多迁移场景文档轻松上云系列之一：本地数据迁移上云https://yq.aliyun.com/article…轻松上云系列之二：其他云数据迁移至阿里云https://yq.aliyun.com/article…轻松上云系列之三：阿里云产品间数据迁移https://yq.aliyun.com/article…轻松上云系列之四：阿里云数据迁移至本地https://yq.aliyun.com/article…轻松上云系列之五：阿里云容灾与备份方案https://yq.aliyun.com/article…阿里云发布迁移解决方案，“迁移上云”这件事有专业的人做https://yq.aliyun.com/article…

摘要： 在没有足够的训练数据时，本文详细介绍了如何使用FloydHub、fast.ai和PyTorch进行迁移学习。现在，人工智能的发展处于跳跃式阶段，我们也对AI在大型数据集的应用进展感到吃惊。更重要的是，那些我们没有跟踪的数十亿张照片或餐厅的评论并没有被遗漏掉：迁移学习技术让收集数据变得更加“容易”。另外，得益于PyTorch框架、fast.ai应用程序库以及FloydHub公司，小团队或者是个别开发人员也能轻松的应用这些方法。本文要讲的例子就是ULMFiT：Jeremy Howard和Sebastian Ruder在fast.ai展示了如何用几百个标记准确的对电影评论进行分类。除此之外，还有一个在通用英语文本语料库中训练的模型。除了英语文本资料库和标记对评论进行分类外，fast.ai还有一个小技巧，它拥有大量特定领域的文本：10万多个样本评论，来展示普通英语和电影评论之间的区别。这引发了我们的思考：至少得需要多少数据，才足以弥合训练示例和通用语言模型之间的差距？这并不是一个特别愚蠢的问题。Frame可以帮助Zendesk，Intercom和Slack等规模性公司标记、评价和理解与客户的对话。也就是说， “只要有足够的对话，我们就可以手动评价”和“我们有足够的数据从头训练一个模型”，这二者之间有很大的差距。仅仅几十个标签和几千条相关对话，这能够做什么？事实证明，这非常有用。在本文中，我们将使用相同的电影评论数据集来证明：即便是只有少部分的数据，数据迁移依然可以有效。更加详细的代码请参考ULMFiT。迁移什么？深度神经网络是当前最新人工智能背后的关键技术，比如理解图像、音频或文本。深度神经网络的核心是它由层（“深度”）组成，每个层都将输入转换为更接近网络训练答案的新的表示。我们通常会抱怨，不了解神经网络的中间层到底发生了什么……其实，它们通常被设计为更加清晰、可解释的角色！比如：很多语言模型利用嵌入层将单个单词或短语进行分类，将具有相似含义的单词或短语放在一起。举个例子来说，这将有助于翻译AI在需要使用“杰出”（illustrious）这个词的时候，会根据经验选择使用“伟大”（great）。现在变得更有趣了：一个“知道”“illustrious = great”的层不仅有利于翻译，还可以学习情绪估计，将不同的观点聚集起来。这就是迁移学习，也就是说模型在一个任务中学习到的东西可以对另外一个学习任务有帮助。事实上，这个特殊的例子特别受欢迎，以至于改进的通用语言模型已经成为一个全新的领域！ 迁移学习不仅有利于任务之间的转移：它可以帮助一般模型在特定环境中更好的工作。例如：一个通用的英语情绪模型或许可以预测电影评论，但是可能不知道“紧张、紧张的惊悚”是件好事。这就是Jeremy和Sebastian Rudder的通用语言模型微调文本分类（ULMFiT）的用武之地。他们对一个包含100,000个IMDB评论的通用语言模型做了改进。即便是只标记几百个单词，其余的单词也能够帮助AI学习审稿人经常用“杰出”或“很好”代替“紧张、紧绷”等，这很好的弥补了数据不足的缺陷。结果的准确度令我们感到惊讶：仅仅有500个标记示例，分类的准确度却高达94%。未被标记的数据最少需要多少？ULMFiT为NLP提供了一个有力的依据，使模型能够更有效的利用较小的数据集。在这项研究中，我们专注于回答以下问题：如果我们对标记示例的预算特别少，那么，得需要收集多少未标记的数据才能有效的使用迁移学习？为了解决这个问题，我们使用了大量固定的域数据池，并改变了标记示例的数量，来看看模型应该如何改进。将标记示例的数量保持不变，并改变未标记的其他域示例的数量。也就是说，我们的实验包括：1.语言建模（变量）2.语言任务（不变量）我们的语言任务、情感分类和原始的ULMFiT论文中的任务相同，另外，也使用了IMDB电影评论数据集。在实验中，标记情绪训练样本的数量保持在500个，500个样本可以用于很多小领域的研究，并且，有助于强调不同语言模型的差异提升能力。对于语言建模，我们改变了可用于语言任务的三种语言模型的域数据量：仅限ULM：这是使用Wikitext103预训练英语语言模型仅限域（domain）：仅在IMDB数据上的基于域训练的模型。ULM +域（domain）：ULMFiT模型训练这些模型的计算量特别大，最大的域训练可能需要几天的时间才能完成。为了加快训练速度和有效的执行网格搜索，我们使用了FloydHub。结果经过大约50个小时GPU处理，结果如下：从实验结果，我们可得知：使用33％的域数据，就可以获得75％数据的UMLFiT性能。令人惊讶的是，ULM + 2,000域示例的语言任务预测准确率约为85％。本文作者：【方向】阅读原文本文为云栖社区原创内容，未经允许不得转载。