数据库当作数字化用户的中枢钞票,其搬动是一项复杂且蹙迫的任务,十分是在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)查验触发器是否搬动告成

在主义端实施大呼查询欧洲杯体育,参考“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的查验源端是否存在触发器”。