正文 

当前位置： 首页 > java > java教程

mycat生产实践---数据迁移与扩容实践

wangshuang1631 wangshuang1631     2022-08-27     479

关键词：

1 离线扩容缩容

工具目前从mycat1.6开始支持。
一、准备工作
1、mycat所在环境安装mysql客户端程序
2、mycat的lib目录下添加mysql的jdbc驱动包
3、对扩容缩容的表所有节点数据进行备份，以便迁移失败后的数据恢复
二、扩容缩容步骤
1、复制schema.xml、rule.xml并重命名为newSchema.xml、newRule.xml放于conf目录下
这里写图片描述
2、修改newSchema.xml和newRule.xml配置文件为扩容缩容后的mycat配置参数（表的节点数、数据源、路由规则）
3、修改conf目录下的migrateTables.properties配置文件，告诉工具哪些表需要进行扩容或缩容,没有出现在此配置文件的schema表不会进行数据迁移，格式：
这里写图片描述
4、修改bin目录下的dataMigrate.sh脚本文件，参数如下：

tempFileDir 临时文件路径,目录不存在将自动创建
isAwaysUseMaster默认true:不论是否发生主备切换，都使用主数据源数据，false：使用当前数据源
mysqlBin：mysql bin路径
cmdLength mysqldump命令行长度限制 默认110k 110*1024。在LINUX操作系统有限制单条命令行的长度是128KB，也就是131072字节，这个值可能不同操作系统不同内核都不一样，如果执行迁移时报Cannot run program "sh": error=7, Argument list too long 说明这个值设置大了，需要调小此值。
charset导入导出数据所用字符集 默认utf8
deleteTempFileDir完成扩容缩容后是否删除临时文件 默认为true
threadCount并行线程数（涉及生成中间文件和导入导出数据）默认为迁移程序所在主机环境的cpu核数*2
delThreadCount每个数据库主机上清理冗余数据的并发线程数，默认为当前脚本程序所在主机cpu核数/2
queryPageSize 读取迁移节点全部数据时一次加载的数据量 默认10w条

5、停止mycat服务（如果可以确保扩容缩容过程中不会有写操作，也可以不停止mycat服务）
6、通过crt等工具进入mycat根目录，执行bin/ dataMigrate.sh脚本，开始扩容/缩容过程：
这里写图片描述
7、扩容缩容成功后，将newSchema.xml和newRule.xml重命名为schema.xml和rule.xml并替换掉原文件，重启mycat服务，整个扩容缩容过程完成。
三、注意事项：
1) 保证拆分表迁移数据前后路由规则一致
2) 保证拆分表迁移数据前后拆分字段一致
3) 全局表将被忽略
4) 不要将非拆分表配置到migrateTables.properties文件中
5) 暂时只支持拆分表使用mysql作为数据源的扩容缩容
四、优化
dataMigrate.sh脚本中影响数据迁移速度的有4个参数，正式迁移数据前可以先进行一次测试，通过调整以下参数进行优化获得一个最快的参数组合

threadCount脚本执行所在主机的并行线程数（涉及生成中间文件和导入导出数据）默认为迁移程序所在主机环境的cpu核数*2
delThreadCount每个数据库主机上清理冗余数据的并发线程数，默认为当前脚本程序所在主机cpu核数/2，同一主机上并发删除数据操作线程数过多可能会导致性能严重下降，可以逐步提高并发数，获取执行最快的线程个数。
queryPageSize 读取迁移节点全部数据时一次加载的数据量 默认10w条
cmdLength mysqldump命令行长度限制 默认110k 110*1024。尽量让这个值跟操作系统命令长度最大值一致，可以通过以下过程确定操作系统命令行最大长度限制：
逐步减少100000，直到不再报错
/bin/sh -c "/bin/true $(seq 1 100000)"
获取不报错的值，通过wc –c统计字节数，结果即操作系统命令行最大长度限制（可能稍微小一些）

这里写图片描述
这里写图片描述

2 案例一：使用一致性Hash进行分片

当使用一致性Hash进行路由分片时，假设存在节点宕机/新增节点这种情况，那么相对于使用其他分片算法(如mod)，就能够尽可能小的改变已存在key映射关系，尽可能的减少数据迁移操作。当然一致性hash也有一个明显的不足，假设当前存在三个节点A,B,C，且是使用一致性hash进行分片，如果你想对当前的B节点进行扩容，扩容后节点为A,B,C,D，那么扩容完成后数据分布就会变得不均匀。A,C节点的数据量是大于B,D节点的。
据测试，分布最均匀的是mod，一致性哈希只是大致均匀。数据迁移也是，迁移量最小的做法是mod，每次扩容后节点数都是2的N次方，这样的迁移量最小。但是mod需要对每个节点都进行迁移，这也是mod的不足之处。总之，还得酌情使用，根据业务选择最适合自己系统的方案。
2.1 配置使用
rule.xml：定义分片规则 

<tableRule name="sharding-by-murmur"> 
<rule> 
<columns>SERIAL_NUMBER</columns> <algorithm>murmur</algorithm> 
</rule> </tableRule> 
<function name="murmur" class="org.opencloudb.route.function.PartitionByMurmurHash"> 
<property name="seed">0</property> 
<property name="count">2</property> 
<property name="virtualBucketTimes">160</property> 
</function>

tableRule定义分片规则

  • name：分片规则的名字。在schema.xml文件中调用。
  • columns：根据数据库中此字段进行分片。
  • algorithm：值是分片算法定义处的name属性。比如：murmur。

function定义一致性Hash的参数

  • seed：计算一致性哈希的对象使用的数值，默认是0。
  • count：待分片的数据库节点数量，必须指定，否则没法分片。
  • virtualBucketTimes：虚拟节点。默认是160倍，也就是虚拟节点数是物理节点数的160倍。指定virtualBucketTimes可以使一致性hash分片更加均匀。
  • bucketMapPath：用于测试时观察各物理节点与虚拟节点的分布情况，如果指定了这个属性，会把虚拟节点的murmur
    hash值与物理节点的映射按行输出到这个文件，没有默认值，如果不指定，就不会输出任何东西。必须是绝对路径，且可读写。
    schema.xml：定义逻辑库，表、分片节点等内容 
<?xml version="1.0" encoding="utf-8"?> <!DOCTYPE mycat:schema SYSTEM "schema.dtd">
<mycat:schema xmlns:mycat="http://org.opencloudb/">
    <schema name="mycat" checkSQLschema="false" sqlMaxLimit="100">
        <table name="T_CMS_ORDER" primaryKey="ORDER_ID" dataNode="dn202_3316"
            rule="sharding-by-murmur" />
    </schema>
    <dataNode name="dn202_3316" dataHost="lh202_1" database="poc" />
    <dataHost name="lh202_1" maxCon="2000" minCon="10" balance="0"
        writeType="0" dbType="mysql" dbDriver="native">
        <heartbeat>select user()</heartbeat>
        <writeHost host="master_host-m1" url="10.21.17.202:3316"
            user="usr" password="pwd"></writeHost>
        <writeHost host="savle_host-m1" url="10.21.17.201:3317"
            user="usr" password="pwd"></writeHost>
    </dataHost>
</mycat:schema>

server.xml：定义用户以及系统相关变量，如端口等。没有太高要求的可以只修改数据库部分。 

<user name="mycat"> <property name="password">usr</property> <property name="schemas">pwd</property> </user>

经过以上配置就可以使用一致性hash了。
2.2 一致性Hash的数据迁移
开始迁移
进行一致性hash进行迁移的时候，假设你新增加一个节点，需要修改以下两个配置文件：
rule.xml 

<function name="murmur" class="org.opencloudb.route.function.PartitionByMurmurHash"> <property name="seed">0</property>
<property name="count">3</property> <property name="virtualBucketTimes">160</property> <!-- <property name="weightMapFile">weightMapFile</property> <property name="bucketMapPath">/home/usr/mycat/bucketMapPath</property> --> </function>

需要把节点的数量从2个节点扩为3个节点。
schema.xml

<?xml version="1.0" encoding="utf-8"?> <!DOCTYPE mycat:schema SYSTEM "schema.dtd">
<mycat:schema xmlns:mycat="http://org.opencloudb/">
    <schema name="mycat" checkSQLschema="false" sqlMaxLimit="100">
        <table name="T_CMS_ORDER" primaryKey="ORDER_ID" dataNode="dn202_3316,dn201_3316"
            rule="sharding-by-murmur" />
    </schema>
    <dataNode name="dn202_3316" dataHost="lh202_1" database="poc" />
    <dataNode name="dn201_3316" dataHost="lh201_1" database="poc" />
    <dataHost name="lh202_1" maxCon="2000" minCon="10" balance="0"
        writeType="0" dbType="mysql" dbDriver="native">
        <heartbeat>select user()</heartbeat>
        <writeHost host="master_host-m1" url="10.21.17.202:3316"
            user="usr" password="pwd"></writeHost>
        <writeHost host="savle_host-m1" url="10.21.17.201:3317"
            user="usr" password="pwd"></writeHost>
    </dataHost>
    <dataHost name="lh201_1" maxCon="2000" minCon="10" balance="0"
        writeType="0" dbType="mysql" dbDriver="native">
        <heartbeat>select user()</heartbeat>
        <writeHost host="master_host-m1" url="10.21.17.201:3316"
            user="usr" password="pwd"></writeHost>
        <writeHost host="savle_host-m1" url="10.21.17.202:3317"
            user="usr" password="pwd"></writeHost>
    </dataHost>
</mycat:schema>

需要添加新节点的dataNode和dataHost信息，以及在schema中的table标签下把新增节点的dataNode的name增加到dataNode的值中。
2.3 开始迁移
使用org.opencloudb.util.rehasher.RehashLauncher类进行数据迁移。参数以命令行的形式进行载入。如 

-jdbcDriver=xxxxx -jdbcUrl=.... -host=192.168.1.1:3316 -user=xxxx -password=xxxx -database=xxxx
  • jdbcDriver：数据库驱动。如com.mysql.jdbc.Driver。
  • jdbcUrl：连接数据库的url，不同数据库不一样。如jdbc:mysql://10.21.17.201:3316/mycat?rewriteBatchedStatements=true。
  • host：包括主机名和端口，形如ip:port。如10.21.100.86:3316
  • user：连接数据库的用户名。如usr
  • database：数据库的名字。如mycat。
  • password：连接数据库的密码。如pwd。
  • tablesFile：记录数据表的文件，一个表一行。
  • shardingField：数据库中进行分片的字段。
  • rehashHostsFile：这个参数没有用到，按照当时的要求，这个类一次只处理一个节点，所以不需要配置
  • hashType：是MURMUR hash还是mod hash。
  • seed：生成一致性hash对象的参数。默认为0。
  • virtualBucketTimes：虚拟节点的倍数。默认为160。
  • weightMapFile：节点的权重，没有指定权重的节点默认是1。以properties文件的格式填写，以从0开始到count-1的整数值也就是节点索引为key，以节点权重值为值。所有权重值必须是正整数，否则以1代替。
  • rehashNodeDir：一个linux目录，这个程序执行完了，把计算结果输出到这个目录，一个表一个文件存在这个目录里，文件名是表名。
    如果你觉得使用命令行的方式去读取配置不是那么方便，你也可以自己定义读取配置文件的算法，只要能保证org.opencloudb.util.rehasher.RehashLauncher这个类能够读到所有的配置就可以了。比如使用properties文件保存配置文件(每次修改配置文件后都需要重新编译)，本着怎么方便怎么写代码的原则，就是这么任性。
    运行org.opencloudb.util.rehasher.RehashLauncher后生成的文件格式如下：
    这里写图片描述
    为了方便进行迁移，我们可以对代码进行适当的修改，如
    这里写图片描述
    通过此种方式拼装，生成的文件如下：
    这里写图片描述
    形如(15666100001,15666100013,15666100023,15666100028)，这个就可以作为in条件了。 生成文件后，可以在linux环境下通过shell的方式进行数据迁移，当然前提是你得停机。
    迁移脚本如下： 
rehashNode=$1 
expanNode=$2 
order_fn="$3" 
if [ "$#" = "0" ]; then 
echo "Please input parameter, for example:" 
echo "ReRouter.sh 192.168.84.13 192.168.84.14 /home/mycat/T_CMS_ORDER " 
echo " " 
exit fi; 
echo "需要进行迁移的主机总量为:$#, 主机IP列表如下:" 
for i in "$@" 
do 
echo "$i" 
done 
echo " " 
#取出rehash需要的SerNum(已经用in拼接好) 
for n in `cat $order_fn` 
do
condOrder=$n 
done echo "************* 导出 *************" 
date 
# 1) 首先调用mysqldump进行数据导出 
echo "开始导出主机:$ 表:T_CMS_ORDER." 
mysqldump -h$rehashNode -P3316 -upoc -ppoc123 poc T_CMS_ORDER --default-character-set=utf8 --extended-insert=false --no-create-info --add-locks=false --complete-insert --where=" SERIAL_NUMBER in $condOrder " > ./T_CMS_ORDER_temp.sql 
echo "导出结束." 
echo " " 
echo "************* 导入 *************" date 
# 2) 调用mycat接口进行数据导入 
echo "开始导入T_CMS_ORDER表数据" 
mysql -h$expanNode -P8066 -upoc -ppoc123 poc --default-character-set=utf8 < ./T_CMS_ORDER_temp.sql echo "导入结束." 
echo " " 
echo "************* 删除数据 *************" date 
# 3) 当前两步都无误的情况下,删除最初的导出数据. 
echo "开始删除已导出的数据表:." 
mysql -h$rehashNode -P3316 -upoc -ppoc123 -e "use poc; DELETE FROM T_CMS_ORDER WHERE SERIAL_NUMBER in $condOrder ; commit; " 
echo "删除结束."
echo " " 
echo "************* 清空临时文件 *************" date 
# 4) 清空临时文件 rm ./t_cms_order_temp.sql 
echo "清空临时文件" 
echo "#####################主机:$rehashNode 处理完成#####################" 
date 
echo " " echo "ReHash运行完毕."

假设文件名是：ReHashRouter.sh

  • 授权：chmod +x ReHashRouter.sh
  • 运行：./ReHashRouter.sh 10.21.17.200 10.21.17.201
    /home/mycat/T_CMS_ORDER

3 案例二：使用范围分片

在使用范围分片算法进行路由分片时，配置非常简单。如下：
3.1 配置使用
rule.xml：定义分片规则 

<tableRule name="auto-sharding-long">
    <rule>
        <columns>user_id</columns>
        <algorithm>rang-long</algorithm>
    </rule>
</tableRule>
<function name="rang-long"
    class="org.opencloudb.route.function.AutoPartitionByLong">
    <property name="mapFile">autopartition-long.txt</property>
</function>

tableRule定义分片规则

  • name：分片规则的名字。在schema.xml文件中调用。
  • columns：根据数据库中此字段进行分片。
  • algorithm：值是分片算法定义处的name属性。比如：rang-long。

function定义范围分片的参数
可以看到根据范围自动分片的配置文件非常简单，只有一个mapFile(要赋予读的权限),此mapFile文件定义了每个节点中user_id的范围，如果user_id的值超过了这个范围，那么则使用默认节点。当前版本代码中默认节点的值是-1，表示不配置默认节点，超过当前范围就会报错。当然你也可以在property中增加defaultNode的默认值，如： 

<property name="defaultNode">0</property>

mapFile节点配置文件
当前版本提供了一个mapFile配置文件供大家参考和使用，如下 

# range start-end ,data node index 
# K=1000,M=10000. 0-500M=0 500M-1000M=1

所有的节点配置都是从0开始，及0代表节点1，此配置非常简单，即预先制定可能的id范围到某个分片。
(tips:K和M的定义是在org.opencloudb.route.function.NumberParseUtil中定义的,如果感兴趣的同学可以自己定义其他字母。)
扩容
如果业务需要或者数据超过当前定义的范围，需要新增节点，则可以在文件中追加 1000M-1500M=2 即可。当然新增的节点需要在schema.xml中进行定义。 

# range start-end ,data node index 
# K=1000,M=10000. 0-500M=0
500M-1000M=1 1000M-1500M=2

4 数据迁移的注意点

4.1 迁移时间的确定
在进行迁移之前，我们得先确定迁移操作发生的时间。停机操作需要尽可能的让用户感知不到，你可以观察每段时间系统的吞吐量，以此作为依据。一般来说，我们选择在凌晨进行升级操作。
4.2 数据迁移前的测试
需要做一些相关的性能测试，在条件允许的情况下在类似的环境中完全模拟，得到一些性能数据，然后不断的改进，看能够否有大的提升。
我们在做数据迁移的时候，就是在备份库中克隆的一套环境，然后在上面做的性能测试，在生产上的步骤方式都一样，之后在正式升级的时候就能够做到心中有数。什么时候需要注意什么，什么时候需要做哪些相关的检查。
4.3 数据备份
热备甚至冷备，在数据迁移之前进行完整的备份，一定要是全量的。甚至在允许的情况下做冷备都可以。数据的备份越充分，出现问题时就有了可靠的保证。
lob数据类型的备份，做表级的备份（create table nologging….)，对于lob的数据类型，在使用imp,impdp的过程中，瓶颈都在lob数据类型上了，哪怕表里的lob数据类型是空的，还是影响很大。自己在做测试的时候，使用Imp基本是一秒钟一千条的数据速度，impdp速度有所提升，但是parallle没有起作用，速度大概是1秒钟1万条的样子。
如果在数据的导入过程中出了问题，如果有完整快速的备份，自己也有了一定的数据保证，要知道出问题之后再从备份库中导入导出，基本上都是很耗费时间的。
4.4 数据升级前的系统级检查

  • 内存检查。可以使用top,free -m来做一个检查，看内存的使用情况是否正常，是否有足够的内存空间。
  • 检查cpu,io情况。查看iowait是否稳定，保持在较低的一个幅度。
  • 检查进程的情况。检查是否有高cpu消耗的异常进程，检查是否有僵尸进程，排查后可以杀掉。
  • 是否有crontab的设置。如果在升级的时候有什么例行的job在运行，会有很大的影响，可以使用crontab -l来查看crontab的情况。
  • vxfs下的odm是否已经启用。如果使用的veritas的文件系统，需要检查一下odm是否正常启用。
  • IO 简单测试。从系统角度来考虑，需要保证io的高效性。可以使用iostat,sar等来评估。
  • 网络带宽。数据迁移的时候肯定会从别的服务器中传输大量的文件,dump等，如果网络太慢，无形中就是潜在的问题。可以使用scp来进行一个简单的测试。
    4.5 异常情况
    网络临时中断。网络的问题需要格外重视，可能在运行一些关键的脚本时，网络突然中断，那对于升级就是灾难，所以在准备脚本的时候，需要考虑到这些场景，保留完整的日志记录。
    可以使用nohup来做外后台运行某些关键的脚本。这样网络断了以后，还有一线希望。在数据迁移，数据升级的时候，一定要保留完整的日志记录，这样如果稍候有问题，也可以及时查验，也可以避免很多不必要的纷争。如果有争议，可以找出日志来，一目了然。
    当然，这样会有大量的日志产生，一定需要保证归档空间足够大，及时的转移归档文件。排除归档爆了以后数据的问题，使用sqlloader,impdp等数据迁移策略的时候，如果归档出了问题，是很头疼的问题。

5 load data批量导入

load data infile语句可以从一个文本文件中以很高的速度读入一个表中。性能大概是insert语句的几十倍。通常用来批量数据导入。目前只支持mysql数据库且dbDriver必须为native。Mycat支持load data自动路由到对应的分片。Load data和压缩协议mycat从1.4开始支持。
5.1 语法和注意事项
标准示例： 

load DATA local INFILE 'd:\88\qq.txt' IGNORE INTO TABLE test CHARACTER SET 'gbk' FIELDS TERMINATED BY ',' OPTIONALLY ENCLOSED BY '"' LINES TERMINATED BY '\n'(id,sid,asf) ;

注意：如果数据中可能包含一些特殊字符，比如分割符转义符等，建议用引号扩起来，通过OPTIONALLY ENCLOSED BY ‘”’指定。如果这样还不行，可以把字段值中的引号替换成\”。
如果指定local关键词，则表明从客户端主机读文件。如果local没指定，文件必须位于mycat所在的服务器上。
可以通过fields terminated by指定字符之间的分割符号，默认值为\t
通过lines terminated by可以指定行之间的换行符。默认为\n,这里注意有些windows上的文本文件的换行符可能为\r\n，由于是不可见字符，所以请小心检查。
character set 指定文件的编码，建议跟mysql的编码一致，否则可能乱码。其中字符集编码必须用引号扩起来，否则会解析出错。
还可以通过replace | ignore指定遇到重复记录是替换还是忽略。
目前列名必须指定，且必须包括分片字段，否则没办法确定路由。
其他参数参考mysql的load data infile官方文档说明。
注意其他参数的先后顺序不能乱，比如列名比较在最后的，顺序参考官方说明。
标准load data语句： LOAD DATA语句,同样被记录到binlog,不过是内部的机制.
例子： 导出：

select * from tblog_article into outfile '/test.txt' FIELDS TERMINATED BY '\t' OPTIONALLY ENCLOSED BY '' ESCAPED BY '\\' LINES TERMINATED BY '\n';

导入： 

load data local infile '/var/lib/mysql/blog/test.txt' INTO TABLE tblog_article FIELDS TERMINATED BY '\t' OPTIONALLY ENCLOSED BY '' ESCAPED BY '\\' LINES TERMINATED BY '\n' (id,title,level,create_time,create_user,create_user,article_type_id,article_content,istop,status,read_count );

5.2 客户端配置
如果是mysql命令行连接的mycat，则需要加上参数–local-infile=1。Jdbc则无需设置。
Load data测试性能
在一台win8下 ，jvm 1.7 参数默认，jdbc连接mycat。
这里写图片描述
测试结果load data local导入1百万数据到5个分片耗时10秒，1千万数据到5个分片耗时145秒。

6 使用mysqldump进行数据迁移

mysqldump是mysql自带的命令行工具。可以用它完成全库迁移（从一个mysql库完整迁移到mycat），也可以迁移某几个表，还可以迁移某个表的部分数据。
6.1 全库迁移
迁移前准备
迁移前确保mysql库和mycat库中的表名一样（mycat库中只需要有表名配置在schema.xml文件中即可）
从mysql导出
从mysql库上全库导出 mysqldump -c -–skip-add-locks databaseName> /root/databaseName.sql
注意：（上面的语句没有-uroot -ppassword参数，是因为mysql服务器设置了本机免密码等。
如果设置了密码:通过以下命名导出(用户名为root，密码为123456)： mysqldump -uroot -p123456 -c -–skip-add-locks databaseName> /root/databaseName.sql
）
说明:两个参数不可少，如下：
-c参数不可少，-c, 全称为–complete-insert 表示使用完整的insert语句(用列名字)。
-–skip-add-locks表示导数据时不加锁，如果加锁涉及多分片时容易导致死锁。
导入到mycat
将databaseName.sql拷贝到mycat集群中的一台mysql服务器上/root目录下。
连接mycat：
mysql -uusername -ppassword -h172.17.xxx.xxx -P8066
切换到指定的数据库： use databaseName;
导入脚本： source /root/databaseName.sql;
6.2 迁移一个库中的某几个表
只是导出命令不同，其他与全库迁移一样 

mysqldump -c -–skip-add-locks databaseName table1 table2> /root/someTables.sql

7 迁移一个表中的部分数据

迁移一个表中的部分数据，加参数–where实现。
命令如下： 

mysqldump -c -–skip-add-locks databaseName tableName --where=" id > 900 " > /root/onetableDataWithCondition.sql

mycat实战之分片迁移

实践扩容1.要求:travelrecord表定义为10个分片,尝试将10个分片中的2个分片转移到第二台MySQL上,并完成记录要求,最快的数据迁移做法,中断业务时间最短2.针对分片以及迁移方式mycat中分片可以理解为dbn而dbn可以是单独datahost中的某个d... 查看详情

实践丨rabbitmq通过shovel插件迁移数据

前言生产环境中会遇到RabbitMQ数据迁移的场景，例如：切换云服务厂商、不同Region之间数据迁移、新搭建RabbitMQ实例，数据需要同步至新的RabbitMQ实例。前提条件：源RabbitMQ实例打开了shovel插件。目的RabbitMQ实例打开了shovel插件。... 查看详情

最佳实践：使用后如何修改flyway迁移脚本

...101:37:40【问题描述】：我正在寻找以下案例的建议。我在生产环境中设置了flyway迁移脚本。在每次部署时，数据库都会迁移到当前版本。我已经创建了几个已应用于生产数据库的迁移脚本。最近我升级了我的开发MySQL工具， 查看详情

同程旅行hadoop集群跨机房迁移实践

本文作者：郭飞。现任同程旅行技术专家。ApacheHadoop、Hive、Spark  contributor 背景随着同程旅行业务和数据规模越来越大，原有的机房不足以支撑未来几年的扩容需求，同时老机房的保障优先级也低于新机房。为了不... 查看详情

通过googledrive备份与同步keepass数据库

摘要：在大流量高并发互联网应用实践在线峰会上，阿里云数据库专家罗龙九结合历年双十一活动中云数据库保障经验，从弹性扩容、访问链路、架构设计、高可用配置、性能优化、参数优化六个方面详解讲解云数据库大流量峰... 查看详情

利用kettle进行sqlserver与oracle之间的数据迁移实践

Kettle简介Kettle（网地址为http://kettle.pentaho.org/）是一款国外开源的ETL工具，纯java编写，可以在Windows、Linux、Unix上运行，数据抽取高效稳定。Kettle中文名称叫水壶，该项目的主程序员MATT希望把各种数据放到一个壶里，然后以一种... 查看详情

mycat开发实践---mycat的网络通信框架

1从一个测试说起网上有人对Cobar和MyCAT做了一个简单的比较测试，过程如下：1测试环境利用A、B、C三大类服务器，在A台上面安装配置MyCAT及Cobar，这样保证了硬件方面的一致性。B类服务器上安装Apache这一web服务，使用PHP语言。C... 查看详情

Laravel 迁移 - 永远保留它们？啥是最佳实践？

】Laravel迁移-永远保留它们？啥是最佳实践？【英文标题】：LaravelMigrations-keepthemforever?Whatisbestpractice?Laravel迁移-永远保留它们？什么是最佳实践？【发布时间】：2015-04-2503:05:58【问题描述】：我已经与Laravel合作了大约几个月-喜... 查看详情

SQL Server 2008 架构更改的最佳实践

...在寻找有关以下方面的信息：将开发数据库的架构更新到生产数据库的最佳实践是什么，或者更简洁地进行一般的数据库架构更改。生产数据库是两个不同ASP.NET网站的后端。我们的架构更改过程相当稳健，每个“迁移”实际上... 查看详情

微服务实践：从单体式架构迁移到微服务架构

...进程间通信微服务实战（四）：服务发现的可行方案以及实践案例微服务实践（五）：微服务的事件驱动数据管理微服务实战（六）：选择微服务部署策略微服务实践（七）：从单体式架构迁移到微服务架构微服务实践（总）-... 查看详情

Flyway 最佳实践：一个大型迁移脚本与多个增量脚本

】Flyway最佳实践：一个大型迁移脚本与多个增量脚本【英文标题】：Flywaybestpractice:onelargemigrationscriptvsmanyincrementalones【发布时间】：2021-12-0120:37:37【问题描述】：我的任务是使用flyway将一些新的迁移脚本添加到现有应用程序中，... 查看详情

kafka新老集群平滑迁移实践(代码片段)

...息发送与消费的正确性迁移方案双写/双读顾名思义，生产端：消息同 查看详情

Django 最佳实践——迁移数据

】Django最佳实践——迁移数据【英文标题】：DjangoBestPractices--MigratingData【发布时间】：2019-01-0118:45:40【问题描述】：我有一个表格，其中包含必须由用户填写的数据。填充此数据后，状态将更改为“已完成”（状态是数据中的... 查看详情

生产环境中的 Elasticsearch 配置和最佳实践

】生产环境中的Elasticsearch配置和最佳实践【英文标题】：Elasticsearchconfigurationandbestpracticesinproduction【发布时间】：2022-01-1405:49:44【问题描述】：我是使用ELK堆栈的新手，我正在处理存储在物理服务器上的10TB，所以如果有关于多... 查看详情

mycat环境搭建教程收集（待实践）

先收集，后续再实践。http://blog.csdn.net/dreamcode/article/details/44307377http://blog.csdn.net/lanonola/article/details/51513343http://www.cnblogs.com/zhongshiqiang/p/5968768.htmlhttp://blog.csdn.net/wutian713 查看详情

flink在58同城的应用与实践

...冯海涛在FlinkForwardAsia2020分享的议题《Flink在58同城应用与实践》，内容包括：实时计算平台架构实时SQL建设Storm迁移Flink实践一站式实时计算平台后续规划一、实时计算平台架构实时计算平台的定位是为58集团海量数据提... 查看详情

django入门与实践-第21章：迁移（完结）(代码片段)

http://127.0.0.1:8000/boards/1/pythonmanage.pymigrate#boards/models.pyclassTopic(models.Model):views=models.PositiveIntegerField(default=0)#<-herepythonmanage.pymakemigrationspythonmanage.pymigrate 查看详情

mycat集群方案收集（待实践）

先收集，后续再实践。我想，市面上开源方案中，涉及到高可用和负载均衡的部署，无论是哪一个产品应用，都基本离不开LVS+Keepalived+HAProxy+Nginx等等。下面是收集的教程：https://wenku.baidu.com/view/01471427ff00bed5b9f31ddc.htmlhttps://zhuanlan... 查看详情