所以整体使用逻辑备份(mysqldump), 个别大表使用物理备份(导出表空间)
2、和逻辑备份相比，它的优点是备份和恢复的速度更快，因为物理备份的原理都是基于文件的cp。
mysqldump 选项请参考http://wangweiak47.blog.51cto.com/2337362/1589304
mysql安装目录 /usr/local/mysql/ 数据目录/usr/local/mysql/data
从事DBA的行业也有两年多了，在数据备份上无论是理论和实践上，都积累了一些经验，恰逢这两天又出现一些数据备份方面的问题，这里，我将之前遇到过的数据备份方法简单做个整理。
MySQL常见备份方案有以下三种： mysqldump + binlog lvm + binlog xtrabackup 本例为方便演示，数据库里面数据为空。下面开始动手 mkdir /opt/backup #创建备份目录 mkdir -p /data/3309/{data,binlog} cd /usr/local/mysql/ scripts/mysql_install_db --u
LANG="en_us-utf-8" service rpcbind status
手里维护了一些小网站，网站跑在一台最低配的轻量应用服务器上，数据库是自建的MySQL。网站虽小，但是备份数据，也是个刚需。主要是MySQL的数据库备份以及一些本地文件的备份。一直想找一个现成的简单、轻量的解决方案，能够把指定目录或者文件定时自动上传到COS里面备份，但却一直没有找到，所以就只好自己动手了。
买了台服务器 今天整理一篇迁移的文档 前提备份 1.备份原环境下的/opt/app/typecho下usr目录的所有文件(因为这个目录包含了你的主题，插件和上传的文件，它无需被升级) 2.备份原环境下的/opt/app/mysqldata下的所有文件(我的docker-compose配置的mysql的数据卷) 3.最好在备份一下mysql数据
前言 我们试着想一想, 在生产环境中什么最重要？如果我们服务器的硬件坏了可以维修或者换新, 软件问题可以修复或重新安装, 但是如果数据没了呢？这可能是最恐怖的事情了吧, 我感觉在生产环境中应该没有什么比数据更为重要. 那么我们该如何保证数据不丢失、或者丢失后可以快速恢复呢？只要看完这篇, 大家应该就能对MySQL中实现数据备份和恢复能有一定的了解。 为什么需要备份数据？ 其实在前言中也大概说明了为什么要备份数据, 但是我们还是应该具体了解一下为什么要备份数据 在生产环境中我们数据库可能会遭遇各种各样的不测
迁移上云，一般涉及到应用系统及数据库系统，其中数据库系统的迁移是最麻烦的。应用系统的迁移一般采用重新部署或磁盘物理迁移方式，但数据库的迁移方式很多，不同的场景有不同的迁移方式。一般数据库迁移方式有物理、逻辑迁移两种方式，对数据库的迁移讲究中断业务时间最短、数据零丢失。前面，我们讲过到mysqldump进行逻辑迁移，今天我们试一下不同的物理数据迁移方式。
②.[root@localhostsrc]#wget http://repo.mysql.com/mysql57-community-release-el7-8.noarch.rpm
当前xtrabackup的8.0.13已经支持 mysql 8.0.20版本（8.0.20版本对innodb的数据文件模式进行了修改）
在数据库表丢失或损坏的情况下，备份你的数据库是很重要的。如果发生系统崩溃，你肯定想能够将你的表尽可能丢失最少的数据恢复到崩溃发生时的状态。有时，正是MySQL管理员造成破坏。管理员已经知道表已破坏，用诸如vi或Emacs等编辑器试图直接编辑它们，这对表绝对不是件好事！
第一步：[root@localhost ~]# cd /etc/sysconfig/network-scripts/
1、MySQL的特点： 1）多线程、多用户 2）基于c/s（客户端/服务器）架构 3）简单易用、查询速度快 4）安全可靠 2、MySQL编译安装 （*代表键盘上tab键） 1）准备工作：卸载使用rpm方式安装的mysql Rpm -e mysql --nodeps 安装cmake包; Cd /media Tar zxf cmake-* -C /usr/src Cd /usr/src/cmake-* ./configure && gmake && gmake install 2)MySQL
所以, 为了在数据丢失之后能够恢复数据, 我们就需要定期的备份数据, 备份数据的策略要根据不同的应用场景进行定制, 大致有几个参考数值, 我们可以根据这些数值从而定制符合特定环境中的数据备份策略
我们有需要将物理盘上的mysql迁移到ssd上，先说一下生产环境一直有数据产生，且数据量达到500G。 方案一：使用mysqldump，不管是导入导出都太耗时，没有一天拿不下 方案二：直接物理磁盘上拷贝也是非常耗时，拷贝过程中需要停服务，这就导致停服务时间太长。 方案三：这个方案本来是很有优势的，但是实际情况导出导入也需要锁表或锁库，也是需要停服务，本来我们就不需要增量拷贝，innobackupex优势体现在增量拷贝。 方案四：拷贝速度快 综合停服务时间以及操作难易度，最终选择了方案四。 下面描述下操作步骤
这部分是快速学习的最后一部分知识，其中最重要的内容就是源码的打包和软件的安装的学习，由于个人的Linux学习目的就是自己能在阿里云Ubuntu上搭建一个简单的nodejs发布环境。 由于现在均是使用云
我们试着想一想, 在生产环境中什么最重要？如果我们服务器的硬件坏了可以维修或者换新, 软件问题可以修复或重新安装, 但是如果数据没了呢？这可能是最恐怖的事情了吧, 我感觉在生产环境中应该没有什么比数据跟更为重要. 那么我们该如何保证数据不丢失、或者丢失后可以快速恢复呢？只要看完这篇, 大家应该就能对MySQL中实现数据备份和恢复能有一定的了解。 为什么需要备份数据？ 其实在前言中也大概说明了为什么要备份数据, 但是我们还是应该具体了解一下为什么要备份数据 在生产环境中我们数据库可能会遭遇各种各样的不测从而
迁移无小事，所以从开始计划将公司的Greenplum集群迁移，到最后落地，整个过程虽然说不上是波折，但是也算是有不少的故事，各种准备和协调。
前言 上一篇分享了关于MySQL事务的知识，在我们数据库中最重要的就是数据了，所以数据的备份就显的特别的重要！ 为什么要备份数据？ 在生产环境中我们数据库可能会遭遇各种各样的不测从而导致数据丢失, 大概分为以下几种： 硬件故障、软件故障、自然灾害、黑客攻击、误操作（占比例大） 所以, 为了在数据丢失之后能够恢复数据, 我们就需要定期的备份数据, 备份数据的策略要根据不同的应用场景进行定制, 大致有几个参考数值, 我们可以根据这些数值从而定制符合特定环境中的数据备份策略： 能够
🙋♂️声明：本人目前大学就读于大二，研究兴趣方向人工智能&硬件（虽然硬件还没开始玩，但一直很感兴趣！希望大佬带带）
再次统计LSN号码，写入到专用文件xtrabackup checkpoint 记录二进制日志位置 所有备份文件统一存放在一个目录下，备份完成
自从产品转到了 dotNET Core 之后，更深入的接触 Linux和 Docker ，而我每天的工作中，有一部分时间相当于在“兼职”做一些运维的事情。下面是一些在日常中常用的命令，算是个备忘吧。
在日常管理服务器的MySQL备份时，比较常用的压缩备份命令，对于新手掌握命令后，可以快速实现使用tar备份打包数据库的文件操作。
Xtrabackup是 Percona公司开发的一款开源的能够对innodb和xtradb数据库引擎进行数据库热备的工具，支持MySQL、Percona server和MariaDB，是目前较为受欢迎的主流MySQL数据库备份工具
所以，无论是配置任何服务器，我们都必须把不用的服务关闭、把系统权限设置到最小，这样才能保证服务器最大的安全。下面是基于CentOS服务器的安全设置，供大家参考。
创建备份目录 mkdir -p /root/bin mkdir -p /bak/mysql-xback
mysqldump命令将数据库中的数据备份成一个文本文件,表的结构和表中的数据将存储在生成的文本文件中。
为保证数据库的安全和效率，可以使用主从备份，当有写的操作可以在主服务器上操作，操作完之后备份到从服务器上，当有读操作时可以访问从服务器，这样在一定程度上保证了数据库的安全，当主服务器的mysql挂掉之后，数据也不会丢失，同时也提高了数据库的效率。
Keepalived 是一个基于VRRP协议来实现的LVS服务高可用方案，可以利用其来避免单点故障。一个mysql或lvs或nginx服务会有2台服务器运行Keepalived，一台为主服务器（MASTER），一台为备份服务器（BACKUP），但是对外表现为一个虚拟IP，主服务器会发送特定的消息给备份服务器，当备份服务器收不到这个消息的时候，即主服务器宕机的时候，备份服务器就会接管虚拟IP，继续提供服务，从而保证了高可用性。
有一个项目要从云上整体迁移到公司机房内，里面有mysql5.6.20，这个mysql没做过备份，也没主从，然后打算通过xtrabackup先做个全备，然后再做个主从（因为在迁移的阶段，云上服务器还会有新的数据生成，主从是为了确保迁移的数据完整）
一开始我没想那么多, 就把当时的想法表达出来. 所以问题表述没那么详细, 建议描述问题时尽量详细点. 理论上来说, 描述的越详细, 提供的代码就越规范, 正确率高
数据备份不仅仅是开发、运维需要了解、熟练和掌握，一些架构设计或系统设计也需要熟练掌握，以备不时之需。最多的应用应该是编制文档上面的技术方案或者安全方案中涉及。
或者在修改Mysql的配置文件my.cnf修改mysqld选卡下的配置文件，增加以下选项:
备份并清空 /var/lib/mysql (也就是mysql的数据目录)，不清空在之后的恢复过程中会报错
Zabbix 5.0.0beta1 版本开始前端需要使用PHP 7.2以上的版本，目前使用的Centos 7 仅提供PHP 5.4,Zabbix 官方建议使用Red Hat Software Collections中的PHP和Nginx 升级Zabbix 5.0.0beta1。在使用repo.zabbix.com软件包进行升级会发现yum 搜索缺少前端软件包。
(1)由于生产环境采用NGINX ，ZABBIX Server默认使用HTTP，升级后的文件默认存放在usr/share/zabbix，需要拷贝到Nginx 默认目录下
由于 docker 不是实体，所以要把mysql的数据库导出到物理机上，命令如下：
其实XtraBackup也是基于INNODB的 crash-recovery功能来实现的，他是对于数据文件的直接拷贝，为了保证数据内部的一致性，就需要使用到了crash-recovery来确保恢复的数据库是一致性的，而且是可用的。
数据是很重要的，没有备份，删库就只能跑路了，当然这只是玩笑话了。但当数据损坏或者误操作删除数据时，备份就显得尤为重要了，备份可以恢复误删除的数据，备份可以作为我们最后的“救命稻草”。MySQL 也是可以按照服务运行状态分为冷备和热备（即停机和非停机），热备份又可以分为逻辑备份和裸设备备份。按照备份后的内容量又可以分为全量备份和增量备份。
用过的备份方式有:mysqldump、mysqlhotcopy、BACKUP TABLE 、SELECT INTO
摘要：mysql当数据库过大的时候，使用mysqldump的方式进行备份是一种非常慢的操作，500G的数据就够你备份一天一夜，我发现了一种mysql快速备份的方案，它使用文件存储的方式进行备份，支持全量和增量备份，这里所写为全量方式（如果可以接受备份开始到下次恢复之间的数据丢失时使用）。xtrabackup的备份速度很快，不管有多少的数据，备份速度完全是依赖于磁盘的读写速度，还支持压缩、不打断正在执行的事务、自动实现备份检验（用mysqldump会锁表，要加上可重复读--single-transaction才不会影响线上的程序写表，但是写表后的东西在还原的时候就会丢了，这也是全量备份的痛点）
使用mysqldump命令备份时候，--all-databases 可以备份所有的数据库。 使用ignore-table 还可以排除制定的表。但是，mysqldump没有参数可以排除数据库的。 要备份的数据库少的时候，可以通过mysqldump -uroot -p123456 --databases db1 db2 db3 > mysqldump.sql 这样来备份。 但是假如数据库有数十个的话，这样写起来很累人，也很low。解决办法还是有的，看下面： 【下面演示用的mysql用户名的root，密码123456】 mysql -uroot -p123456 -e 'show databases;'|grep -E -v "Database|information_schema|mysql|test" |xargs mysqldump -uroot -p123456 --databases > mysqldump1.sql 但是很不幸的是，在mysql5.5上执行备份时报错了。 查了下资料，发现是由于5.5以后，mysql的performance_schema库导致的。那我们备份时跳过该库即可，下面2种方法任选：
误删数据库应该如何恢复操作？怎样才能做好数据库的备份、恢复、容灾、HA？如果你身处数据库行业，最近可能会比较关注这几个问题
在国内不论是使用阿里云、腾讯云还是华为云的云平台版本的 MySQL 数据库，在遇到数据备份恢复的场景，都会遇到需要使用 Percona XtraBackup 工具进行备份还原的需求。
假设路径分隔符为/，第一个参数为SRC_PATH，第二个参数为DEST_PATH，行为如下：
文件中存放的是frm对应表结构的sql，直接复制出来运行就行了，此时数据库中所有的结构都恢复了，就是还没有数据
领取专属 10元无门槛券
手把手带您无忧上云
