前面几篇文章为大家介绍了 MySQL 各种语句语法的用法及用户权限相关知识。本篇文章将主要讲解 MySQL 数据库数据备份与恢复相关知识,主要聚焦于逻辑备份,介绍mysqldump工具的使用以及恢复方法。
上篇文章介绍了 mydumper 备份工具的使用方法,文中有提到 mydumper 和 myloader 是一对相互的命令,即 mydumper 负责备份(导出),myloader 负责恢复(导入)。那么 myloader 又该如何使用呢?本篇文章我们一起来看下。
备份恢复之前和同事投入了一些精力来完善,算是走上了平台化对接的一个开始,在满足功能的前提下,能够基本实现数据全备,增备和DML闪回,但是在性能和可控性方面还是存在不少的改进之处,最近梳理了下已有的备份恢复策略,准备在这个方面能有一定的成绩。
数据库备份 数据库复制不能取代备份的作用 备份分类: 全量备份:整个数据库的完整备份 增量备份:在上一次备份基础上,对更改数据进行备份。mysqldump不支持这种 逻辑备份:结果为SQL语句,适用于所有存储引擎 物理备份:对数据库目录的靠背,对于内存表只备份结构 备份内容: 备份方式: mysqldump全备介绍 mysqldump备份 mysqldump database [tables] mysqldump --database DB1 [DB2] mysqldump --all-databases
数据是很重要的,没有备份,删库就只能跑路了,当然这只是玩笑话了。但当数据损坏或者误操作删除数据时,备份就显得尤为重要了,备份可以恢复误删除的数据,备份可以作为我们最后的“救命稻草”。MySQL 也是可以按照服务运行状态分为冷备和热备(即停机和非停机),热备份又可以分为逻辑备份和裸设备备份。按照备份后的内容量又可以分为全量备份和增量备份。
本文档将详细介绍如何对 TiDB 进行全量备份与恢复。增量备份与恢复可使用 TiDB Binlog。
墨墨导读:备份恢复是DBA最后一道防线。最近项目碰到备份恢复的相关的事项,结合自己的经验,巩固一下知识。
首先会启动一个xtrabackup_log后台检测的进程,实时检测mysql redo的变化,一旦发现redo有新的日志写入,立刻将日志写入到日志文件xtrabackup_log中 复制innodb的数据文件和系统表空间文件idbdata1到对应的以默认时间戳为备份目录的地方 复制结束后,执行flush table with read lock操作 复制.frm .myd .myi文件 并且在这一时刻获得binary log 的位置 将表进行解锁unlock tables 停止xtrabackup_log进程
这个专栏前 4 节由无为完成,后四节由马听完成,文稿互相审核。总结了两位作者在这些年自己或者朋友遇到过的高频面试题,希望能和你一起讨论这些问题。
那大概是一个春暖花开的季节,我的内心是激动澎湃的,因为已经安排了休假计划。在这前几天,已经把一个新项目的数据库环境都部署好了,包括 自动化备份。
首先看下MySQL误删数据排名最前的几种是什么,然后说几点平时预防误操作导致文件/数据丢失不成熟的建议,最后再说万一发生误操作时,怎么以最快速度进行补救。
全备份的优点是备份保持最新备份,恢复的时候可以花费更少的时间;缺点是如果数据量大,将会花费很多的时间,并对系统造成较长时间的压力。增量备份相反,只需要备份每天的增量日志,备份时间少,对负载压力也小;缺点就是恢复的时候需要全备份加上次备份到故障前的所有日志,恢复时间长一些。
最近在看TiDB的系统管理课程,对TiDB周边的配套工具做了一下了解,今天总结下。
热备中主要有逻辑备份和裸文件备份,裸文件备份要比逻辑备份在速度上快一些,mysqldump 备份方式是采用的逻辑备份,其最大的缺陷是备份和恢复速度较慢,如果数据库大于 50G,mysqldump 备份就不太适合。而 XtraBackup 是一种物理备份工具,支持热备,在备份时复制所有 MySQL 的数据文件以及一些事务日志信息,在还原时将复制的数据文件放回至 MySQL 数据目录,并应用日志保证数据一致。
OceanBase 数据库采用了单集群多租户设计,天然支持云数据库架构,支持公有云、私有云、混合云等多种部署形式。
一般情况我们通过mysqldump来备份MySQL数据库,并上传至其它备份机器。如果数据库比较大,在备份传输的时候可能会慢,所以我们尽量让备份的文件小一些。
log_bin binlog的开关和binlog的前缀
所以在我们引入前从以下六个方面分别对 TiDB 进行测试验证,其中功能与架构、配置与管理、备份与恢复都是针对我们运维管理,SQL 特性、基准测试、应用场景测试则是应对业务需求和业务场景的。
很多年前,被公司外派到一家单位驻场开发一个OA项目,两个开发对接各部门的需求,需求还要及时生效(一边开发一边使用)。
MySQL的备份恢复是一直想要改进的地方,其中恢复是重中之重,这部分的工作要做成平台化的工作,算是有了前期的很多铺垫和延迟,最近在和同事的共同协作下,总算有了一些眉目出来。
数据库作为基础设施,其安全性不言而明,因此数据安全备份和恢复功能是在严肃使用场景下的标配。TiDB 作为一款分布式数据库,目前可以满足超大集群的备份恢复的需求,经过测试,10T 数据的备份恢复速度可以达到 GB/s 级别。这得益于我们研发的分布式备份恢复工具 Backup&Restore That Scales(以下简称 BR)。
学习一款数据库,要学会备份和恢复。备份是一个严谨的工作,作为一个dba,掌握数据库备份、恢复的各种手段。
MySQL 逻辑备份工具最常用的就是 mysqldump 了,一般我们都是备份整个实例或部分业务库。不清楚你有没有做过恢复,恢复场景可能就比较多了,比如我想恢复某个库或某个表等。那么如何从全备中恢复单库或单表,这其中又有哪些隐藏的坑呢?这篇文章我们一起来看下。
对于MySQL方向的备份恢复设计,其实是作为数据保障工作最基础的事情了,备份的重要性就不需要反复强调了。对于数据备份的必要性我在团队内的一个要求就是,如果没有从库,不需要备份,基本可以判定这个业务可以下线了。
今天梳理了一下备份恢复方向的内容,目前备份方向已经充分验证了功能,在数据恢复方向的功能可行,但是在性能和效率上还是存在较大的改进空间。
使用flashback工具,原理是修改binlog的内容,拿回原库重放。需要binlog格式为row格式,并且binlog_row_image=FULL
1. 主:binlog线程——记录下所有改变了数据库数据的语句,放进master上的binlog中;
通过GreatADM可视化的方法,屏蔽手动命令操作的复杂度,快速完成单实例的向多主、多副本的架构分钟级的调整升级。
转自:https://www.cnblogs.com/waynechou/p/xtrabackup_backup.html 阅读目录 xtrabackup 选项 xtrabackup 全量备份恢复 xtrabackup 增量备份恢复 前一篇文章我们讲到了PXB的原理以及安装方法,接下来将详细介绍 XtraBackup 备份和恢复的具体过程。 回到顶部 xtrabackup 选项 xtrabackup 工具有许多参数,具体可去官网查询(xtrabackup 参数选项 | innobackupex 参数选项),
优点: mysqldump的优点就是逻辑备份,把数据生成SQL形式保存,在单库,单表数据迁移,备份恢复等场景方便,SQL形式的备份文件通用,也方便在不同数据库之间移植。对于InnoDB表可以在线备份。
MySQL Shell 是官方提供的 MySQL 周边适配组件,是新一代的高级客户端,在 MySQL 8.0 及其以后的版本得以慢慢推广应用。之前笔者因为 MySQL 8.0 用得比较少,一直没有详细使用过这个工具,近期在捣鼓 MySQL 8.0,趁此机会,一起来学习下吧。
如果是使用 delete 语句误删了数据行,可以用 Flashback 工具通过闪回把数据恢复回来。 Flashback 恢复数据的原理,是修改 binlog 的内容,拿回原库重放。而能够使用这个方案的前提是,需要确保 binlog_format=row 和 binlog_row_image=FULL。
Flashback恢复数据的原理是通过修改binlog内容,拿回原库进行回放,前提是binlog_format=row和binlog_row_image=FULL。
mydumper 最突出的特性就是可采用多线程并行备份,极大提高了数据导出的速度。其特征之一是在处理过程中需要对列表加以锁定,所以备份时尽量不要选择工作时间,避免引起 DML 阻塞。若是主从架构的话,从库一般处于只读状态,则可以直接在从库上执行备份操作,不会有 DML 堵塞了。
最近完成了初版的数据逻辑备份恢复的功能,和业务方做了一些交流和演示,发现他们对于备份恢复侧的一些东东还是不够敏感,因为因为一些术语的差异,他们不大理解所谓的备份恢复能干什么,所以我们做了一些讨论,最后决定改为“数据克隆”。
区别在于TPCC测试的业务流程,sysbench测试的单语句执行性能。按照自需选择测试工具。
对于数据恢复来说,现在其实缺少一些有效的使用场景来更好的体现业务价值,于是我们就重新考虑了下现有的备份支持能力。
如果一个线上数据库发生了问题,需要做数据恢复,作为DBA应该给自己留一些改进的余地,否则陷入两难的境地,只会让自己更加被动。
今天,几乎绝大多数现代化企业的业务,都是一定程度上在处理数据。从处理大量用户的财务数据的金融机构,到处理每个用户手机 APP 上交易、娱乐、社交数据的个人,数据都在企业经营中发挥中重要的作用,数据安全是企业最重要的事情并不为过。就在几周前,大洋彼岸的美国发生全美航班停飞数小时的重大安全故障,此次全美航班停飞是 911 事件以来首次发生。据美国航空监管机构报道,这次事故原因是数据库文件受损,可见企业容灾备份的重要性。
Bytebase是一款面向开发者的数据库变更管理工具,目前在Github上已有3.6K+Star。
XtraBackup是Percona推出的一款备份工具,算是对于mysqldump的一个补充。对于大批量数据的导入使用mysqldump会出现一定的瓶颈,这一点做过一些数据迁移项目的同学可能感同身受。
从InnoDB redo log file实时拷贝走备份期间产生的所有redo日志
08.14自我总结 数据库的备份 一数据库的备份 1.单库备份 mysqldump -uroot -p123 db1 > db1.sql #库名 mysqldump -uroot -p123 db1 table1 table2 > db1-table1-table2.sql #库名 表名 2.多库备份 mysqldump -uroot -p123 --databases db1 db2 mysql db3 > db1_db2_mysql_db3.sql 3.备份所有库 mysqldump -uroot -
Xtrabackup 是由 percona 开源的免费数据库热备份软件,它能对 InnoDB 和 XtraDB 存储引擎的数据库非阻塞地备份。
作为小站长,mysql数据库算是比较常用的了。作为运维,肯定遇到过数据被误删的情况。下面模拟数据库为误操作删除后的恢复过程。
官网下载:https://www.percona.com/downloads/XtraBackup/LATEST/
资深数据库专家,专研 MySQL 十余年。擅长 MySQL、PostgreSQL、MongoDB 等开源数据库相关的备份恢复、SQL 调优、监控运维、高可用架构设计等。目前任职于爱可生,为各大运营商及银行金融企业提供 MySQL 相关技术支持、MySQL 相关课程培训等工作。
每每看到行业内的数据事故,我们在感慨之余,更需要的就是自省,因为这可以敲响我们已有状态的警钟。微盟技术团队从一个创业团队一路走来,逐步建立了较为成熟的安全管理规范,对服务器和数据访问权限有着明确的分层和分级的授权管理制度,这次虽然有疏忽,实际上也是受害者。
领取专属 10元无门槛券
手把手带您无忧上云