最近在mysqldump时，遭遇mysqldump: Error 2013错误。以为是常见的参数设置有问题，调整之后，也没有任何成效。原来发生了OOM，以下是其具体描述。 一、故障现象 环境 # more /etc/redhat-release CentOS Linux release 7.

【数据存储与数据库】  【服务器】  【mysql】  【LOG】  【数据库】  【mysqldump】   …

mysqldump备份用法小结

【mysql】  【SQL】  【数据库】  【脚本】  【database】  【mysqldump】  【dump】   点击查看原文>

一个简单的案例，引发出对mysqldump一点全新的认识。

【数据存储与数据库】  【mysql】  【replication】  【binlog】  【mysqldump】   点击查看原文>

0、导读

   用mysqldump备份数据时，加上 -w 条件选项过滤部分数据，发现导出结果比实际少了40万，什么情况？

   本文约1500字，阅读时间约5分钟。

1、问题

   我的朋友小文前几天遇到一个怪事，他用mysqldump备份数据时，加上了 -w 选项过滤部分数据，发现导出的数据比实际上少了40万。

   要进行备份表DDL见下：

   CREATE TABLE `oldbiao` (

   `aaaid` int(11) NOT NULL,

   `bbbid` int(11) NOT NULL,

   `cccid` int(11) NOT NULL,

   `time` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP,

   `dddid` int(11) DEFAULT NULL,

   KEY `index01` (`ccccid`),

   KEY `index02` (`dddid`,`time`)

   ) ENGINE=InnoDB DEFAULT …

--- title: MySQL · myrocks · myrocks之备份恢复 author: 张远 ---

myrocks支持逻辑备份和物理备份，逻辑备份仍然采用mysqldump，物理备份采用自己开发的myrocks_hotbackup工具，传统的物理备份工具Xtrabackup不支持rocksdb。

【数据存储与数据库】  【备份】  【mysql】  【innodb】  【阿里技术协会】  【path】   …

   写在前面：我们在使用mysqldump备份数据时，请一定记住要加上 -q 参数，后果可能是很严重的，不要给自己挖坑哦。到底为什么呢，且听我慢慢道来！

   先来看看 mysqldump -help 中，关于 -q 参数的解释：

-q, --quick         Don't buffer query, dump directly to stdout.

   简言之，就是说加上 -q 后，不会把SELECT出来的结果放在buffer中，而是直接dump到标准输出中，顶多只是buffer当前行结果，正常情况下是不会超过 max_allowed_packet 限制的，它默认情况下是开启的。

   如果关闭该参数，则会把SELECT出来的结果放在本地buffer中，然后再输出给客户端，会消耗更多内存。

  …

写在前面：我们在使用mysqldump备份数据时，请一定记住要加上 -q 参数，后果可能是很严重的，不要给自己挖坑哦。到底为什么呢，且听我慢慢道来！

先来看看 mysqldump –help 中，关于 -q 参数的解释：

-q, --quick         Don't buffer query, dump directly to stdout.

简言之，就是说加上 -q 后，不会把SELECT出来的结果放在buffer中，而是直接dump到标准输出中，顶多只是buffer当前行结果，正常情况下是不会超过 max_allowed_packet 限制的，它默认情况下是开启的。

如果关闭该参数，则会把SELECT出来的结果放在本地buffer中，然后再输出给客户端，会消耗更多内存。

…

   我们在用mysqldump备份数据时，有个选项是 -where / -w，可以指定备份条件，这个选项的解释是：

-w, --where=name    Dump only selected records. Quotes are mandatory

   我们可以做个测试，例如：

mysqldump --single-transaction -w ' id < 10000 ' mydb mytable > mydump.sql

   这时候就可以备份出mytable表中 id< 10000 的所有记录了。假设我们还想加一个时间范围条件，例如：

mysqldump --single-transaction -w " id < 10000 and logintime < unix_timestamp('2014-06-01')" mydb mytable > mydump.sql

   在这里，一定注意单引号和双引号问题，避免出现这种情况：

mysqldump --single-transaction -w ' id < 10000 and logintime < unix_timestamp('2014-06-01') ' mydb mytable > mydump.sql

   这样的话，结果条件会被解析成： …

   背景

   MySQL全量逻辑备份恢复最基础的方法，就是mysqldump生成文本，再通过source 命令直接导入。一般用于实例迁移或者版本升级。

   这里说明最近碰到的一个失败例子。

   描述

   这个例子可以简要复现如下，在源库上执行如下操作:

   use mydb;

   create table t1 (id int);

   create view v1 as select * from t1;

   drop table t1;

   之后执行 mysqldump mydb，发现mysqldump中途退出。简化后出错原因很明显，就是视图v1对应的表t1已经不存在，这个视图本身非法。

  …

我们在部署MySQL Replication从库时，通常是一开始就做好一个从库，然后随着业务的变化，数据也逐渐复制到从服务器。

但是，如果我们想对一个已经上线较久，有这大数据量的数据库部署复制从库时，应该怎么处理比较合适呢？

本文以我近期所做Zabbix数据库部署MySQL Replication从库为例，向大家呈现一种新的复制部署方式。由于Zabbix历史数据非常多，在转TokuDB之前的InnoDB引擎时，已经接近700G，转成TokuDB后，还有300多G，而且主要集中在trends_uint、history_uint等几个大表上。做一次全量备份后再恢复耗时太久，怕对主库写入影响太大，因此才有了本文的分享。

我大概分为几个步骤来做Zabbix数据迁移的：

1、初始化一个空的Zabbix库 …