越来越多的生产系统和关键应用运行在K8S上。在生产系统运行有状态应用,并不是一件容易的事情,它需要我们仔细的计划并部署。我们之前有一篇文章专门介绍如何在K8S上运行高可用的MySQL。这次我们来介绍下如何备份和恢复MySQL。当我们在生产环境中备份和恢复MySQL,我们需要思考下面的问题:
针对存储引擎为myisam的表,能够直接复制frm、myd、myi这三个文件起到备份的效果。须要还原的时候,再复制回来就能够达到还原效果。
今天是《MySQL核心知识》专栏的第14章,今天为大家系统的讲讲MySQL中的数据备份与恢复,希望通过本章节的学习,小伙伴们能够举一反三,彻底掌握MySQL中的数据备份与恢复相关的知识。好了,开始今天的正题吧。
MySQL 备份一般采取全库备份加日志备份的方式,例如每天执行一次全备份,每小时执行一次二进制日志备份。这样在 MySQL 故障后可以使用全备份和日志备份将数据恢复到最后一个二进制日志备份前的任意位置或时间。
备份的本质就是将数据集另存一个副本,但是原数据会不停的发生变化,所以利用备份只能恢复到数据变化之前的数据。那变化之后的呢?所以制定一个好的备份策略很重要。
1. 做灾难恢复:对损坏的数据进行恢复和还原 2. 需求改变:因需求改变而需要把数据还原到改变以前测试:测试新功能是否可用
MySQL 数据库管理系统通常会采用有效的措施来维护数据库的可靠性和完整性。但是在数据库的实际使用过程当中,仍存在着一些不可预估的因素,会造成数据库运行事务的异常中断,从而影响数据的正确性,甚至会破坏数据库,导致数据库中的数据部分或全部丢失。
1.数据库的备份 备份=拷贝加管理,防止数据的丢失同时记录用户的操作记录。其中最有效的备份是对IT架构进行备份。 原则: (1)数据库要定期备份,备份的周期应当根据应用数据系统可承受的恢复时间,而且定期备份的时间应当在系统负荷最低的时候进行。对于重要的数据,要保证在极端情况下的损失都可以正常恢复。 (2)定期备份后,同样需要定期做恢复测试,了解备份的正确可靠性,确保备份的有意义的、可恢复的。 (3)根据系统需要来确定是否采用增量备份,增量备份只需要备份每天的增量数据,备份花费的时间少,对系统负载的压力也
数据库在信息系统中担任着非常重要的角色,尤其一些对数据可靠性要求非常高的行业,如果发生宕机或数据丢失,其损失是非常严重的。 在公司中备份的策略并不是千篇一律的,而是根据每个企业 的实际生产环境与业务需求制定合适的备份策略。无论是选择完全备份还是增量备份,都需要考虑它们的优缺点,是否适合当前的生产环境。同时为了保证恢复的完整性,建议开启二进制日志功能,二进制日志文件给恢复工作带来了很大的灵活性,可以基于时间点或位置进行恢复,考虑到数据库性能,可以将二进制日志文件保存在其他安全的硬盘中。
MySQL实时增量备份,采用binlog日志的好处 掌控所有更改操作,必要时可用于恢复数据 数据库主从复制的必要条件
大体上差不多,不过8.0版本移除了innobackupex命令且只能备份8.0版本的MySQL
在生产环境上,为了避免数据的丢失,通常情况下都会定时的对数据库进行备份。而Linux的crontab指令则可以帮助我们实现对数据库定时进行备份。首先我们来简单了解crontab指令,如果你会了请跳到下一个内容mysql备份。 本文章的mysql数据库是安装在docker容器当中,以此为例进行讲解。没有安装到docker容器当中也可以参照参照。
上次我们介绍了采用逻辑备份mysqldump 备份方式,其最大的缺陷就是备份和恢复速度都慢,但如果数据库非常大,那再使用 mysqldump 备份就不太适合了。这时就需要一种好用又高效的工具,xtrabackup 就是其中一款,号称免费版的 InnoDB HotBackup。(mysqldump备份请到L宝宝聊IT公众号中找“mysql备份与还原——mysqldump结合binlog”文章)
版权声明:Copyright © https://blog.csdn.net/zzw19951261/article/details/80997699
搭建从库,本质上需要的只是一个一致性备份集及这个备份集对应的位置点信息。之前介绍的几个备份工具( MySQL中如何选择合适的备份策略和备份工具 )均可满足。
备份完成后可以看到在/oradata/data/mysql/xtra目录下新建了以日期命名的目录
在生产机器上通常是要备份数据库的,主要是防止重要数据丢失,这里就不细说为什么备份了,这篇文章是MariaDB数据库的逻辑备份
随着自动化办公与电子商务的不断发展,企业对于信息系统的依懒性越来越高,而数据库在信息系统中担任着非常重要的角色。尤其一些对数据可靠性要求非常高的行业,如银行、证券、电信等,如果发生意外宕机或数据丢失,其损失是非常严重的。为此数据库管理员必须针对具体的业务要求制定详细的数据库备份与灾难恢复的策略,并通过模拟故障对每种可能的情况进行严格的测试,从而保证数据的可靠性。
1 Part1 引言 在日常数据库运维中,经常要对数据库进行热备。热备的一个关键点是保证数据的一致性,即在备份进行时发生的数据更改,不会在备份结果中出现。mysqldump是实际场景中最常使用的备份工具之一,通过选择合适的选项做备份,mysqldump可以保证数据的一致性,同时尽可能保证进行中的业务不受影响。 那么mysqldump是如何实现一致性备份的?以下我将结合mysqldump过程中mysqld生成的general log与mysqldump的源码来解释mysqldump一致性备份的原理。 注:
前言 其实前面一篇数据备份已经是非常的详细了,这里我想单独的讲解一下mysqldump,相信很多程序员都是用过这个命令的! 一、MySQL数据库的备份与还原 1.1、MySQL数据库备份 1)语法 mysqldump -u username -p db_name table1 table2 ...> xxx.sql 含义: db_name参数:表示数据库的名称; table1和table2参数:表示需要备份的表的名称,为空则整个数据库备份; xxx.s
一、日志 1.redo、undo 2.mysql主要的日志:1、错误日志2、查询日志(普通查询日志和慢查询日志)3、二进制日志
物理备份是将数据库的二进制文件直接拷贝到另一个位置,以达到备份数据库的目的。物理备份可以使用以下方法进行:
MySQL复制全解析 Part 2 一步步搭建基于二进制文件位置的MySQL复制
数据库及时备份可以帮助我们在数据库出现异常宕机时及时的使用备份数据进行恢复工作,将因为数据库宕机产生的影响降低到最小。上一篇针对使用xtrabackup工具进行物理备份和数据恢复做了一个详细讲解,本篇主要谈谈如何使用mysql自带的备份工具mysqldump进行逻辑备份和数据恢复。如果还围观看过上一篇文章的可以先行查询上一篇文章关于使用xtrabackup进行数据备份与恢复:Mysql备份与恢复(1)---物理备份。
点击关注公众号,Java干货及时送达 作者:程淇铭 来源:segmentfault.com/a/1190000020116271 日常工作中,总会有因手抖、写错条件、写错表名、错连生产库造成的误删库表和数据的事情发生,那么,如果连数据都恢复不了,还要什么 DBA。 相关文章 MySQL备份策略:https://segmentfault.com/a/1190000019955399 MySQL数据恢复:https://segmentfault.com/a/1190000020116271 1 前言 数据恢
物理备份是指直接复制包含数据的文件夹和文件。这种类型的备份适用于大数据量且非常重要,遇到问题需要快速回复的数据库。
mysql数据库备份有多么重要已不需过多赘述了,废话不多说!以下总结了mysql数据库的几种备份方案: 一、binlog二进制日志通常作为备份的重要资源,所以再说备份方案之前先总结一下binlog日志~~ 1.binlog日志内容 1)引起mysql服务器改变的任何操作。 2)复制功能依赖于此日志。 3)slave服务器通过复制master服务器的二进制日志完成主从复制,在执行之前保存于中继日志(relay log)中。 4)slave服务器通常可以关闭二进制日志以提升性能。 2.binlog日志文件的文
日常工作中,总会有因手抖、写错条件、写错表名、错连生产库造成的误删库表和数据的事情发生。但是,如果每次删库都跑路的话,怕是再也不好找工作了吧!所以,删库跑路不是上上策。
虽然mysqldump工具是数据库系统的首选备份方法,但它仅在数据库服务器可运行时才有效。如果无法启动数据库或无法访问主机系统,我建议直接复制数据库。
一、mysqldump备份方式是采用逻辑备份。最大的缺陷就是备份和恢复的速度都慢,对于一个50G的数据库而言,这个速度还是可以接受的,但是如果数据库非常大,那在使用mysqdump备份就不是太合适了。。
XtraBackup工具详解 Part 5 使用innobackupex对数据库进行全备
MySQL备份一般采用全库备份加日志备份的方式,根据业务的需要,可以采用每周日凌晨1点进行完全备份以及每小时进行一次增量备份,这样在MySQL故障后可以使用完全备份和日志备份尽可能的去恢复最完整的数据。 一、binlog日志恢复 MySQL的二进制日志记录着该数据库所有增删改的操作日志(前提是需要自己开启binlog),还包括了这些操作的执行时间,binlog的使用场景无外乎就是主从同步以及恢复数据库。开启binlog功能,需要编辑MySQL的主配置文件,如下: 1、查看二进制功能是否开启(如下,值为OFF,则表示未开启):
单独备份表的话需要表在独立的表空间里面,即配置了innodb_file_per_table参数
感谢本文译者田川 ! 欢迎更多资深用户翻译原厂博文(https://blog.zabbix.com/)!
日常工作中,总会有因手抖、写错条件、写错表名、错连生产库造成的误删库表和数据的事情发生,那么,如果连数据都恢复不了,还要什么 DBA。
备份的主要目的是灾难恢复,备份还可以测试应用、回滚数据修改、查询历史数据、审计等。
使用活动数据库系统时遇到的一个很常见的挑战是执行热备份,即在不停止数据库服务或将其设置为只读的情况下创建备份。简单地复制活动数据库的数据文件通常会导致内部不一致的数据库副本,即它将无法使用或者将在复制期间丢失。另一方面,停止数据库以进行计划备份会使应用程序的数据库相关部分变为不可用。Percona XtraBackup是一个开源实用程序,可用于解决此问题,并为运行MySQL,MariaDB和Percona Server数据库(也称为热备份)创建一致的完整备份或增量备份。
1、复制date文件夹备份 ============================ 假想环境: MySQL 安装位置:C:\MySQL 论坛数据库名称为:bbs 数据库备份目的地:C:\db_bak\ ============================ 新建db_bak.bat,写入以下代码 *******************************Code Start***************************** net stop mysql xcopy c:\mysql\data\bbs\*.* c:\db_bak\bbs\%date:~0,10%\ /S /I net start mysql *******************************Code End ***************************** 然后使用Windows的“计划任务”定时执行该批处理脚本即可。(例如:每天凌晨3点执行back_db.bat) 解释:备份和恢复的操作都比较简单,完整性比较高,控制备份周期比较灵活,例如,用%date:~0,10%。此方法适合有独立主机但对mysql没有管理经验的用户。缺点是占用空间比较多,备份期间mysql会短时间断开(例如:针对30M左右的数据库耗时5s左右),针对%date:~0,10%的用法参考 。 2、mysqldump备份成sql文件 ============== 假想环境: MySQL 安装位置:C:\MySQL 论坛数据库名称为:bbs MySQL root 密码:123456 数据库备份目的地:D:\db_backup\ 脚本: rem *******************************Code Start***************************** @echo off
误删数据库应该如何恢复操作?怎样才能做好数据库的备份、恢复、容灾、HA?如果你身处数据库行业,最近可能会比较关注这几个问题
基于前面的文章方法,加入批处理命令即可实现自动备份。只是由于批处理命令中对于备份文件的名字按照时间命名比较特别,所以特别整理一文。
冷备份: 这些备份在用户不能访问数据时进行,因此无法读取或修改数据。这些脱机备份会阻止执行任何使用数据的活动。这些类型的备份不会干扰正常运行的系统的性能。但是,对于某些应用程序,会无法接受必须在一段较长的时间里锁定或完全阻止用户访问数据。
如果在开始备份时没有指定--flush-logs参数,则需要首先查看备份时所处的位置
午休正酣,一个电话打散了睡意。电话那头的第一句话便是“开发童鞋写update SQL的时候忘了加where条件了!”相信每一名DBA,听到这个消息,心里都会有一种想骂街的冲动!万幸的是,只是单表写花了,而不是哪位大神在DB里面玩drop table。虽然已经很久没进行单表恢复了,但大致步骤都还在脑海中,没花多久就搞定了~
使用活动数据库系统时遇到的一个非常常见的挑战是执行热备份,即在不停止数据库服务或将其设置为只读的情况下创建备份。简单地复制活动数据库的数据文件通常会导致内部不一致的数据库副本,即它将无法使用或者将丢失在复制期间发生的事务。另一方面,停止数据库以进行计划备份会使应用程序的数据库相关部分变为不可用。Percona XtraBackup是一个开源实用程序,可用于解决此问题,并为运行MySQL,MariaDB和Percona Server数据库(也称为热备份)创建一致的完整备份或增量备份。
领取专属 10元无门槛券
手把手带您无忧上云