磁盘中mysql数据太大怎么清理 开拓数据迁移新方案？
开拓数据迁移新方案？
数据库迁移到总体有四种方法我们今天以mysql为例，来说说数据库迁移的四种方法。
1、将数据库倒出为sql文件，再新的再导入（帮我推荐）。必须将mysql数据库锁定，并将内存中的数据写入磁盘。用mysqldump将test数据库导入为sql文件。在新的数据库服务器上，空白文档test数据库，再将sql文件文件导入。该方法因按结构sql命令参与数据库迁出，兼容性最好是，准确性极高，但速率最慢。
2、将数据库的文件存档目录然后拷贝至新主机。可以真接将mysql存储数据的目录剪切粘贴过去，用ftp等上传成功至新主机的对应存储数据的目录下。该操作必须关掉两端的数据库服务，否则将出现错误。该方法只意见myql的MyIASM的表引擎。该方法迁移速度快，但因Mysql设置成区分inno引擎，适用场景少，且数据库版本升级后出错率高。
3、在用第三方数据库迁移工具。mysql有很多第三方的数据库迁移工具，如mysqlcheck。此类工具一般允许热迁移（不中断业务，实时动态写数据），允许物理内容复制。该方法迁移速度快，对业务掉线时间短，但我建议你迁移到多参与模拟测试，尽量的避免意外事件。甚至连有一些第三方的迁移工具意见异构网络数据库的迁移。
4、使用整盘迁移工具。区分云主机的第三方迁移工具，将整个磁盘文件直接进行迁出。该方法迁移速度快，对业务关闭时间短，但成本高，好象为收费工具。
Mysql实时备份实现方法？
数据备份是数据容灾的最后一道防线，就算有着两地三中心的架构，系统备份也仍然重要。如果没有备份文件出问题，系统备份时影响了交易业务，备份数据无法完全恢复，这些也企业无法承受的。因为中,选择合适的备份工具尤为重要。
每个企业级数据库都会有对应的备份工具，MEB(MySQL Enterprise Backup)应该是MySQL企业版中非常重要的工具之一，是为企业级客户需要提供的数据备份方案。
Xtrabackup一直都才是MEB闭源版备胎而未知，从MySQL8.0又开始情况很可能会变地有所完全不同。
在MySQL8.0的BackupLock、Redo Log Archiving、Page Tracking等新特性的加持下，MEB软件备份/可以恢复可以体验会更好，目前xtrabackup还不允许这些特性。
MySQL企业版另外哪些功能？
特性1：BackupLock
8.0之前在用xtrabackup或MEB做物理系统备份，就是为了能保证系统备份时InnoDB引擎表与其他引擎数据文件、及binlog日志的一致性会上全局读锁，再文件复制非InnoDB文件，这期间MySQL会变得只读模式，数据难以写入文件。表数量一定，肯定而且时间越长，假如不使用的xtrabackup一不小心没加rsync参数，逐个拷贝frm文件，完全锁定时间会更长，对业务影响较大。
我曾遇到过防御部署在虚拟机的实例有12000多张表，当时建议使用的xtrabackup，备份文件脚本中没加rsync参数，可是锁了十几分钟，而MEB就没有这样的问题。
MySQL8.0支持什么轻量级系统备份锁LOCKINSTANCEforBACKUP，数据字典也重新架构了由InnoDB存储。若不创建非InnoDB表，MEB设置在用系统备份锁声望兑换binlog日志一致性位置，并阻拦DDL能操作，但不会影响DML能操作。
只有一InnoDB表，仅上系统备份锁
若有非InnoDB表，上全局锁
特性2：RedoLogArchiving
MEB能可以做到网热备，软件备份时不影响大数据库读写，这是借用了InnoDB事务日志，在系统备份期间短短监视redolog的变化，读取增量变化，写入到到ibbackup_logfile，也就不要上锁来保障备分一致性。(对非InnoDB的文件是需要上读锁拷贝)
如果备分期间数据库中写入负载尤其大，而读取ibbackup_logfile速度较慢，redologsize也不大，很可能会会直接出现ibbackup_logfile的写入文件速度跟不上进度redolog记录生成速度，redolog空间不够时不需要覆写日志文件，这样来不及中写入ibbackup_logfile的记录会丢了，倒致系统备份我失败了。
MEB4.1对此做了优化，将redolog处理线程拆分成多线程分工合作，增强一次性处理redolog的效率，减低了redolog覆写导致备分一次的概率，但redolog再新增速度和ibbackup_logfile中写入速度悬殊太大，问题仍然会突然发生。
MySQL8.0.17支持了redologarchiving完全可以解决了此问题，备份前设置innodb_redo_log_archive_dirs，委托redolog归档目录。MEB系统备份时自动启动传送日志归档，当checkpoint时会将旧记录归档来此目录，后续从归档文件中读取数据redo日志记录，避免了覆写可能会导致的redo记录全部丢失。
尽量：innodb_redo_log_archive_dirs不能不能在数据目录下，目录权限要求是700
特性3：PageTracking
PageTracking是为优化增量备份文件效率，减少不必要的数据页扫描。
增量软件备份当前有3种扫描模式：
page-track：利用LSN最精确监视那次系统备份之后被改页面，仅剪切粘贴这些页面，效率最多。
optimistic：系统扫描那次软件备份之后被改的InnoDB数据文件中，得出答案并文件复制直接修改的页面。感情依赖系统时间，可以使用必然限制。
endless-scan：扫描系统所有InnoDB数据文件，判断并拷备自刚才备份之后直接修改的页面，效率最慢
1、依靠page-track增量备份，需先安装好备份文件组件
2、在全备前再开启page-track
3、全备之后，做增量软件备份时委托若行最简形矩阵pagetracking条件，设置成会在用page-track模式，不然的话会使用clear-scan模式，也这个可以指定你--incrementalpage-track。
incremental-base有3种选择
last_replication：实现前三次备分做增备，前两次系统备份很有可能是增备，也可能是全备。这种全备之间很有可能会有多个增备，有时候增量可能都很小，但恢复时要逐个合并。
last_large_backup：基于条件前四次全备做增备。这种增备会越往前体积很有可能越大，但重新恢复时只是需要合并最后一次机会增量软件备份。
dir：设计和实现前一次的备份目录，前一次备分可能是增备，也可能会是全备。
测试综合比large-scan和page-track，在需要变更页大于1总体50%的情况下，备份效率至多能有1倍的速度进阶。
page-track模式磁盘读写均衡，只能证明读写的大都直接修改页面。
wide-scan模式磁盘读写差别不大，只能证明读了很多未修改的页面。
版权声明：本文内容由互联网用户自发贡献，本站不承担相关法律责任.如有侵权/违法内容,本站将立刻删除。
