开yun体育网“全量+增量迁徙”类型任务-开云官网kaiyun皇马赞助商 (中国)官方网站 登录入口
发布日期：2026-01-17 14:46 点击次数：55
数据库动作数字化用户的中枢钞票,其迁徙是一项复杂且病笃的任务,相称是在VMware平台替换及IT基础设施更新换代之时,尤其需要保险数据库迁徙过程的牢固、指点。
肯定服推出的数据库管制平台(DMP)是为关联型数据库量身打造的运维管观念决有经营,它整合了数据库日常运维所需的各项功能,包括但不限于数据库的创建、实时监控、数据备份以及灾难复原等。此外,DMP 还配备了先进的数据库迁徙器用DTS,使企业粗疏将数据库从VMware平台或物理干事器无缝迁徙至肯定服的云规划环境中,确保了迁徙过程的高恶果、安全性和可靠性。
肯定服为知足用户不同场景下的迁徙需求,提供丰富的MySQL数据库迁徙有经营:
SCMT信服云迁徙器用粗疏完结针对常见单机数据库的迁徙,复旧点对点模式、热备模式等多种迁徙方式,操作浮浅,对业务影响小。
DTS数据库迁徙器用是肯定服数据库管制平台DMP针对迁徙场景拓荒的专用器用,复旧主从同步迁徙,通过成立MySQL的主从复制,将数据从主库同步到从库,然后进行扮装切换。频频情况下接纳全量+增量的迁徙方式,然则当5.6 -> 8.0跨版块迁徙时,由于会存在迁徙后sql语法不兼容的情况,因此需要接纳全量迁徙的方式。
物理备份/逻辑备份迁徙,靠近DMP平台无法知足特定的迁徙条目或要求时,肯定服将谐和专科的数据库群众DBA来制定和扩充定制化的物理备份/逻辑备份迁徙有经营。
本文重心先容使用 DMP 的 DTS 器用对 MySQL 数据库进行全量加增量的数据迁徙方式,亦然现在较为保举的MySQL迁徙方式。它愚弄mydumper/myloader逻辑备份复原手艺与MySQL主从复制旨趣,通过与数据库里面组件的邃密合作,完结数据的高效迁徙。
迁徙复旧版块:
MySQL 5.6 → MySQL 8.0 全量迁徙
MySQL 5.6-5.7 → MySQL 5.7 全量+增量迁徙
MySQL 5.7、8.0 → MySQL 8.0 全量+增量迁徙
迁徙架构复旧:
MySQL 单机 → MySQL 单机
MySQL 主从 → MySQL 主从
MySQL 单机 → MySQL 主从
MySQL 主从 → MySQL 单机
一、DTS 迁徙手艺旨趣
本文重心先容使用DMP的DTS器用对MySQL数据库进行全量加增量的数据迁徙方式,亦然现在较为保举的MySQL迁徙方式,复旧跨版块(5.6-5.7)、复旧跨平台迁徙。
DMP的DTS复旧mydumper + 主从复制方式迁徙,mydumper是一个用于MySQL的开源热备份器用,它不错在不锁定表的情况下进行数据备份。使用mydumper和主从复制方式进行数据迁徙的基本旨趣如下:
源、经营数据库运诊疗数据并建筑主从关联;
从库会生成两个线程,一个I/O线程,一个SQL线程;
I/O线程会去苦求主库的binlog,并将得到的binlog写到土产货的relay-log(中继日记)文献中;
主库会生成一个log dump线程,用来给从库I/O线程传输binlog;
SQL线程,会读取relay-log文献中的日记,并剖析成sql语句逐个扩充。
肯定服DTS数据迁徙器用,通过自动化和法度化的数据迁徙战略,大幅度镌汰操作难度并提提升移恶果。该器用通过直不雅的可视化界面,为用户提供了一站式干事,包括经营数据库的构建、迁徙前的清雅搜检、实时监控迁徙过程以及高效切换限定。这种集成化的方法不仅简化了数据库的创建和性能优化,还确保了用户粗疏精准地掌捏并优化总共这个词迁徙进程,以得当企业对数据库迁徙的复杂和多变需求。
二、DTS 迁徙留心事项
增量迁徙阶段接纳GTID模式的主从同步方式,在迁徙前源端需开启BINLOG,形态为ROW,且掀开GTID,不然只可进行全量迁徙,不成作念“全量+增量”模式迁徙。
由于mydumper器用不复旧迁徙触发器trigger,如源端数据库有触发器且需要迁徙到经营端数据库,需在迁徙完成后手动迁徙触发器trigger。
“全量迁徙”类型任务,在全量备份阶段,源端会出现元数据锁,阻拦DDL语句,因此在此阶段源库无法扩充DDL语句;一样的,“全量+增量迁徙”类型任务,在源库导出阶段时代,源库也无法扩充DDL语句。
MySQL 5.7到MySQL 8.0跨版块“全量+增量迁徙”类型任务时,不复旧源库扩充语句:grant all privileges on *.* to user@'%' identified by 'password';。
“全量+增量迁徙”类型任务迁徙过程中,无法同步源库的创建用户、修改用户权限操作,是以在迁徙过程中应幸免增转换用户权限。
源端存在的空库(database下无任何数据库对象)不会被迁徙。
三、迁徙过程及留心事项
(一)迁徙时代评估
凭证迁徙的数据量和迁徙过程中的操作,总共这个词迁徙过程时代漫衍如下:
主从复制迁徙方法概览
(二)源库信息汇集
在迁徙前需要了解源环境和经营环境的硬件各异,不错评估迁徙的可行性和风险,包括CPU、内存、磁盘基础设施的成立和愚弄率,基于硬件信息的汇集,不错合理打算迁徙战略。
硬件信息汇集走漏
数据库信息汇集是确保迁徙过程中数据一致性的关节。通过汇集数据库的版块、数据量和成立等信息,不错制定清雅的数据迁徙经营和考据有经营。在迁徙过程中,不错通过比拟源数据库和经营数据库的数据各异来实时发现并科罚问题,确保数据的齐全性和一致性。基于数据库信息的汇集,不错制定清雅的迁徙经营,包括迁徙的时代窗口、备份和复原战略、迁徙考据和回滚经营等,减少迁徙过程中的不细目性和风险,确保迁徙的成功进行。
数据库信息汇集走漏
(三)经营数据库成立打算
中枢业务系统数据库在迁徙至肯定服云规划平台时,可能存在CPU和内存成立焦虑,或资源多余的情况,需要对原干事器进行成立变更评估。评估原则如下:
肯定服平台物理主频提议要高于原干事器或者保持持平且不低于2.0GHhz,阻挠云平台的性能低于原操作系统的主频。
合理的CPU和内存平均愚弄率在30%-70%之间,业务岑岭时也应保持在80%以内,当原VMware平台使用率来源70%时,探究在肯定服主机加多成立。
单实例数据库干事器成立提议16C-32C,若是32C还不成知足业务需求,提议优化数据库,排查慢SQL语句;或鼎新数据库架构为集群架构,不提议再通过加多干事器成立来承载业务。
集群数据库干事器提议成立16C-32C,若是32C还不成知足业务需求,提议优化数据库,排查慢SQL语句;或为集群加多新的节点,以承载更多的业务走访,不提议再通过加多干事器成立来承载业务。
数据库内存在迁徙上云时提议加多,不提议镌汰,松弛镌汰数据库干事器内存可能会导致数据库无法启动。成立提议在16G-64G的区间,具体成立需要通过专科的DBA进行规划,迁徙时不可松弛鼎新数据库干事器内存成立。
源端数据库的磁盘使用率不高于70%的情况下,迁徙过来后可保持原状。若是源端磁盘使用率高于70%,在扩容时需探究到改日3-5年的业务增量进行测算。
单实例数据库创建完成后只可修改数据盘/日记盘的大小,不成扩容数目。举例源数据库成立了4块1T磁盘,后头扩盘时只可扩大小,举例扩容到4块2T磁盘。
集群数据库干事,只可加多数据盘/日记盘的数目,不提议扩容大小。举例源数据库成立了4块1T磁盘,后头扩盘只可扩数目,举例扩容到8块1T。
若是是P2V迁徙的系统,磁盘大小成立和原物理的保持一致,数据文献和日记文献场地的磁盘为提高IO的蒙眬,提议将磁盘进行预分派。
(四)切换与回退想象
在清雅扩凑数据迁徙之前,提议将源库克隆出测试库进行一次迁徙测试。这一方法至关病笃,因为不同的物理环境可能会导致迁徙所需的时代出现各异。通过测试迁徙,不仅不错评估迁徙过程中可能遭受的时代问题,并且不错考据迁徙有经营的可行性和灵验性。此外,迁徙测试还有助于识别潜在的问题和风险,从而在清雅迁徙之前采选相应的防护门径。
数据库切换前必须证据业务系统已十足住手对数据库的走访和写入。在进行切换时,DMP允许用户聘任是否在切换过程中自动关闭源数据库。频频情况下,为了确保业务成功上线,咱们会在业务系统上线前相接源数据库进行数据考据,此时无需自动关闭源数据库。关联词,若是无法确保源数据库的数据写入操作已十足住手,或者在切换过程中挂牵源数据有变化,那么在进行切换时聘任自动关闭源数据库将是一个更为稳妥的门径。
数据库迁徙完成后,应更新业务系统相接地址,以确保通过经营数据库的干事IP进行走访。在聚积环境中,若是存在走访限定战略,应在迁徙前诊疗战略,以幸免影响业务走访。若是是白名单模式,容许许最底层的全阻挠战略;若是是黑名单模式,则应在最表层添加允许总共战略。待业务系统十足迁徙后,再再行启用相应的走访限定战略。
在数据库成功迁徙并经过业务考据之后,提议立即进行全面备份。这么,在经营数据库遭受无法赶快科罚的问题时,不错赶快复原到迁徙后的气象。同期,提议保留源数据库的运干事态(但不要关闭干事器),以便在新平台出现问题时,粗疏赶快切换回源数据库连续提供干事。
在数据库迁徙和切换过程中,必须确保源数据库环境的齐全性不受干扰。若是在切换过程中遭受极度,或者在业务考据阶段发现问题,应立即有计划肯定服产物线群众和数据库管制员(DBA)寻求复旧。在允许的时代限制内,应优先会诊问题,诊疗迁徙参数或系统成立,以赶快复原迁徙进程。
在数据库迁徙过程中,若是遭受无法在停机窗口期内赶快科罚的极度问题,应立即回退到源数据库环境。在回退之前,需要分析失败的原因,并凭证分析收尾再行制定迁徙经营。在决定回退时,要确保在迁徙过程中莫得新的业务数据写入到新数据库,以幸免在回退过程中丢失最新的业务数据。
如切换后发现业务有问题,不得不回切至源数据库,不错愚弄割接后的增量日记,生成SQL文献,与用户有计划东说念主员交流明,不错在源端扩充增量还原。
四、迁徙过程阐明
(一)创建迁徙任务
此处以全量+增量迁徙任务,整库迁徙的方式为例,以下是具体的操作方法:
使用DTS迁徙器用新建迁徙任务,迁徙前请确保源库已开启binlog,并开启GTID,GTID(Global Transaction ID,全局事务ID),用来强化数据库的主备一致性、故障复原,以及容错才智。用于取代夙昔传统的主从复制(即:基于binlog和position的复制)。若迁徙任务为全量迁徙情况,则不消开启此参数。
(二)数据迁徙过程
在证据源数据库和经营数据库的成立之后,接下来需要为数据库迁徙竖立实例参数、迁徙干事(DTS-VM,用于扩充迁徙任务的器用,包括数据导出与导入、日记抽取与重放等;不会占用迁徙配额,迁徙完成后将自动删除该云主机并开释对应的资源)成立。当启动DTS器用扩充迁徙任务时,它将自动进行一系列预搜检,包括考据源和经营数据库之间的连通性、用户权限、数据库架构、数据库版块兼容性、字符集、存储引擎、系统信息、迁徙数据量等。预搜检中发现的“欠亨过项”将径直影响迁徙任务的扩充,必须在迁徙前科罚;而“告警项”则频频不会妨碍迁徙过程,不错在东说念主工审核后聘任忽略,连续扩充迁徙任务。
来源进行全量迁徙过程,DTS会完成以下动作:源端数据库全量导出、经营端数据库全量复原。全量迁徙过程中对源库业务不会产生影响,提议在业务低峰期扩充,或者减少并发数并时刻不雅察对出产业务产生的影响。总共DTS操作过程齐会添加时代戳走漏在前端,运维东说念主员可实时监控总共这个词迁徙过程。
在初度全量备份成功完成后,DTS系统将干预不时性的增量同步阶段。增量同步的中枢任务是实时进行主从同步。增量迁徙过程中,DTS会完成以下动作:竖立源&经营端主从关联,重置主库、竖立GTID、主从同步、搜检主从同步气象。在此过程中,经营端会不时获得源端binlog日记文献信息,并愚弄SQL Thread进行回放,从而完结增量同步。这种增量同步操作不会对源数据库的业务运行形成任何影响。
凭证肯定服在用户端的迁徙施行告戒,使用千兆迁徙聚积时,全量数据迁徙的理思速率为30MB/s,这使得每小时约莫粗疏迁徙100GB的数据。关联词,迁徙速率受多种成分影响,包括源数据库的数据结构、物理聚积条目以及带展期制。因此,内容迁徙速率需要凭证具体情况进行评估和诊疗。
(三)停库切换过程
数据库迁徙切换过程需要停库中断业务,在细目了停机时代后,应向各业务部门发布景仰奉告,住手业务和应用对源数据库的走访,幸免产生数据丢失等不测情况产生。同期需谐和业务东说念主员、运维东说念主员、应用厂商、肯定服厂商等多方责任主说念主员协助保险迁徙切换和业务考据责任。
全量迁徙任务待任务扩充完成后,即数据库迁徙结束,完成切换,业务可走访新实例进行业务考据;全量+增量迁徙任务,需手动扩充割接,割接完成后,业务走访新实例进行业务考据。
在数据库切换进程十足扩充结束后,总共源端数据将被成功迁徙至经营端数据库。此时,不错对源端和经营端数据库进行相接,以进行数据的搜检和校验,确保数据库气象的一致性。完成数据校验后,应谐和业务团队成员进行业务走访测试。这一测试过程至关病笃,它确保了从业务角度来看,系统粗疏平日责任,知足业务需求。
五、附录
(一)准备迁徙用户
提议使用数据库全权限用户如root@'%'(和root@'localhost'不是合并个用户)进行迁徙。若是源端不成使用全权限数据库用户扩充迁徙,需在源端创建迁徙用户。创建用户及赋权语句如下:
留心:迁徙用户的密码中迥殊字符仅复旧:()`~!@#$^&*_-+=|{}[]:<>.?/。
MySQL5.6、5.7、8.0 全量迁徙用户权限
mysql> create user dtsuser@'%' identified with mysql_native_password by 'dtspassword';
mysql> grant select,event,show view,lock tables,reload on *.* to dtsuser@'%';
MySQL5.6、5.7、8.0 全量+增量迁徙用户权限
mysql> create user dtsuser@'%' identified with mysql_native_password by 'dtspassword';
mysql> grant select,event,show view,lock tables,replication slave,replication client,reload on *.* to dtsuser@'%';
(二)在线开启GTID
GTID(Global Transaction ID,全局事务ID),用来强化数据库的主备一致性、故障复原,以及容错才智。用于取代夙昔传统的主从复制(即:基于binlog和position的复制)。
若迁徙任务为全量+增量迁徙情况,则必须开启此参数。
以下操作主从均需要扩充:
1.开启GTID预搜检
mysql> set &global.enforce_gtid_consistency=WARN;
开启此参数后,需不雅察MySQL不实日记,若有违背GTID规定的事务会有告警,应实时诊疗。
竖立告警后,部分操作会被告警,请留心诊疗业务或关闭GTID,举例:
(1) 扩充CREATE TABLE ... SELECT语句:
(MySQL8.0.21以后关于复旧原子DDL的存储引擎,举例InnoDB引擎,复旧该操作)
举例:
create table t1 select * from sbtest3;
巡视不实日记:
2023-06-19T11:44:05.956128+08:00 82810 [Warning] Statement violates GTID consistency: CREATE TABLE ... SELECT.
修改:
create table t1 like sbtest3;
insert into t1 select * from sbtest3;
(2) 在事务中扩充CREATE TEMPORARY TABLE or DROP TEMPORARY TABLE语句:
举例:
begin;
select * from sbtest3 for update;
create temporary table t2(id int);
巡视不实日记:
2023-06-19T11:52:42.254719+08:00 82810 [Warning] Statement violates GTID consistency: CREATE TEMPORARY TABLE and DROP TEMPORARY TABLE can only be executed outside transactional context. These statements are also not allowed in a function or trigger because functions and triggers are also considered to be multi-statement transactions.
修改:
幸免在事务中扩充创建或删除临时表。
2.开启GTID校验
mysql> set &global.enforce_gtid_consistency=ON;
这一步一朝扩充,违背GTID的操作齐会被拒却,比如 create table as select,是以上一步WARN阶段确保无违背GTID规定的事务。
3.开启GTID_MODE
mysql> set &global.gtid_mode=OFF_PERMISSIVE;
不雅察ongoing_anonymous_transaction_count值:
mysql> show global status like '%ongoing_anonymous_transaction_count%';
证据仍是莫得匿名的事物,提议多不雅察一段时代,若是不为0,强行修改可能会导致数据丢失。
4.GTID_MODE竖立为ON_PERMISSIVE
mysql> set &global.gtid_mode=ON_PERMISSIVE;
5.GTID_MODE竖立为ON
mysql> set &global.gtid_mode=ON;
6.从库扩充(若源端为单机,忽略此方法)
mysql> stop slave;
mysql> change master to master_auto_position=1;
mysql> start slave;
mysql> show slave status\G
这一步,总共老的relay log齐算帐掉了,新relay log包含的全是GTID操作Event。
7.修改成立文献(持久成功)
若未添加至成立文献,则数据库重启后参数失效,GTID关闭。
主从均扩充
# vim /etc/my.cnf
在mysqld下添加以下内容
[mysqld]
gtid_mode=ON
enforce_gtid_consistency=ON
(三)修改BINLOG_FORMAT
BINLOG_FORMAT是MySQL中的一个参数,用于指定二进制日记文献的形态。MySQL的复制方式与binlog(二进制日记文献)形态一一双应。
mysql复制主要有三种方式:
基于SQL语句的复制(statement-based replication, SBR);
基于行的复制(row-based replication, RBR);
搀和模式复制(mixed-based replication, MBR)。
对应的,binlog的形态也有三种:STATEMENT,ROW,MIXED。
修改BINLOG_FORMAT的方法如下:
1.先在从库扩充、再去主库扩充
mysql> set global binlog_format=ROW;
2.修改成立文献(主从齐修改)
# vim /etc/my.cnf
在mysqld下添加以下内容
[mysqld]
binlog_format=ROW
(四)手动迁徙触发器trigger
1.搜检询敕令默许业务触发器莫得创建在系统数据库中,是以抹杀系统数据库sys、mysql、information_schema、performance_schema。
mysql> select TRIGGER_SCHEMA,count(*) as tiggers_cnt from information_schema.`TRIGGERS` where TRIGGER_SCHEMA not in ('sys','mysql','information_schema','performance_schema') group by TRIGGER_SCHEMA;
如上敕令扩充后有收尾,如图所示,源端业务数据库sakila、test分歧有6、1个触发器,则需要迁徙。
如上敕令扩充后查不到数据,则走漏业务数据库中无触发器需要迁徙。
2.方法一:(保举)
1.在经营端数据库后台扩充如下敕令导出源端触发器。留心:在-B参数后头添加需要导出的业务数据库(即上一章节查询出来的TRIGGER_SCHEMA)的名字,如有多个使用空格分隔。
-h:源端数据库ip地址,如“10.5.54.66”。
-P:源端数据库端标语,如“3306”。
-u:源端数据库迁徙账号,如“root”
-p:源端数据库迁徙账号密码,如“Admin-123”。
# mysqldump -h10.5.54.66 -P3306 -uroot -pAdmin-123 --single-transaction --set-gtid-purged=OFF --default-character-set=utf8mb4 --add-drop-trigger --no-create-db=true --no-create-info=true --no-data=true -B sakila test > ./tri.sql
留心:导出源端触发器用户需要有“trigger”权限。
(2)导入到经营端数据库。
# mysql -uroot -pQwer@123 -S/run/sock/mysql.sock < ./tri.sql
(3)搜检触发器是否迁徙成功
在经营端扩充敕令查询开yun体育网,参考“Part.5 附录中第4节 手动迁徙触发器trigger的搜检源端是否存在触发器”。
3.方法二
1.在经营端用root用户登录RDS主节点,走访源端数据库导出业务数据库触发器DDL语句。
# cd
# rm -rf trigdump.sql
# touch trigdump.sql
# mysql -h10.5.54.66 -P3306 -uroot -pAdmin-123 <<'EOF'
tee trigdump.sql
SELECT
CONCAT("DROP TRIGGER IF EXISTS `",
TRIGGER_SCHEMA,
"`.`",
TRIGGER_NAME,
"`;\nDELIMITER ;;\nCREATE TRIGGER `",
TRIGGER_SCHEMA,
"`.`",
TRIGGER_NAME,
"` ",
ACTION_TIMING,
" ",
EVENT_MANIPULATION,
" ON `",
EVENT_OBJECT_SCHEMA,
"`.`",
EVENT_OBJECT_TABLE,
"` FOR EACH ROW\n",
ACTION_STATEMENT,
";;\nDELIMITER ;") AS TRIG
FROM
information_schema.TRIGGERS
WHERE
TRIGGER_SCHEMA IN ('sakila','test')\G
notee
exit
EOF
# sed -i '/^*/d' trigdump.sql
# sed -i 's/TRIG: //' trigdump.sql
# echo "COMMIT;" >> trigdump.sql
(2)导入触发器至经营端主节点
# mysql -uroot -p -S/run/sock/mysql.sock < trigdump.sql
(3)搜检触发器是否迁徙成功
在经营端扩充敕令查询,参考“Part.5 附录中第4节 手动迁徙触发器trigger的搜检源端是否存在触发器”。