VMware替代实战手册：更高效的MySQL数据库转移决策

数据库四肢数字化用户的中枢钞票,其转移是一项复杂且伏击的任务,非常是在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的查验源端是否存在触发器”。