数据库作为数字化用户的中心资产,其迁徙是一项庞杂且主要的义务,特殊是在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@'%';(二)在线开启GTIDGTID(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_MODEmysql> set @@global.gtid_mode=OFF_PERMISSIVE;察看ongoing_anonymous_transaction_count值:mysql> show global status like '%ongoing_anonymous_transaction_count%';确认曾经不匿名的事物,倡议多察看一段时光,假如不为0,强行修正可能会招致数据丧失。4.GTID_MODE设置为ON_PERMISSIVEmysql> set @@global.gtid_mode=ON_PERMISSIVE;5.GTID_MODE设置为ONmysql> 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=ONenforce_gtid_consistency=ON(三)修正BINLOG_FORMATBINLOG_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(四)手动迁徙触发器trigger1.检讨询下令默许营业触发器不创立在体系数据库中,以是消除体系数据库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.sqlSELECTCONCAT("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 TRIGFROMinformation_schema.TRIGGERSWHERETRIGGER_SCHEMA IN ('sakila','test')\GnoteeexitEOF# 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的检讨源端能否存在触发器”。翻译搜寻复制 　　申明：新浪网独家稿件，未经受权制止转载。 -->