标签: backup

我使用 mysqldump 创建一个用于备份的平面文件。我已使用此文件在备用服务器上重新创建数据库。我在命令行上通过 ssh 运行导入过程，但收到多个Packet too Large错误。

我用更大的 max_allowed_pa​​cket（即 1000M）重新启动了 mysql，但仍然收到错误消息。我什至尝试在导入文件中设置 max_allowed_pa​​cket，仍然收到错误。

有没有办法确保设置 max_allowed_pa​​cket 和/或使用 mysqldump 来创建不会导致此问题的文件？

以供参考：

未压缩的 mysqldump 文件约为 2GB

数据库类型是 INNODB

我们正在使用 SQL Server 2012 的 HADR（AlwaysOn 可用性组）功能。服务器和 AG 配置如下：

1. SQL12_SRV1 --> AG1(PRIMARY) - SYNC -->> DBTest

2. SQL12_SRV2 --> AG1(SECONDARY) -->> DBTest - ASYNC

DBTest 数据库每天都在增长 (200GB)，大约每月和相同的事务日志文件也将根据数据增长。

那么如何通过使用正确的日志备份方法来最小化事务日志文件大小。我们必须在哪个副本上进行日志备份。

提前致谢。

我有一个 centos 服务器，/var/lib/mysql/ 是 125GB（磁盘有 1GB 的可用空间）。

通常我会使用 mysqldump 来备份数据库，但我通常不使用这么大的数据库，所以我需要知道将数据库复制到新服务器的最安全方法。

所有建议表示赞赏！

我想知道自定义 pg_dump 格式在 Postgres 版本之间有多稳定。例如，我可以在 postgres 9.x 中恢复使用 Postgres 8.x 创建的自定义格式转储吗？

背景：

我正在构建一个虚拟设备，其中包含 PostgreSQL 数据库中的所有配置。我必须决定是使用 SQL 格式还是自定义格式进行备份。随着设备随着时间的推移（几年）不断发展，我将使用更新的 PostgreSQL 版本，并且仍然需要能够轻松恢复旧备份。

我有一个 postgres 9.1 服务器正在运行，我用

pg_dumpall -c -f /nfs/backup/fulldump.sql

我正在测试将备份恢复到另一台服务器

psql -f /nfs/backup/fulldump.sql

以用户身份运行时postgres出现两个错误

psql:/nfs/backup/fulldump.sql:27: ERROR:  current user cannot be dropped
psql:/nfs/backup/fulldump.sql:36: ERROR:  role "postgres" already exists

我知道这些是由命令引起的

DROP ROLE postgres;
CREATE ROLE postgres;

在备份转储中。

是否有可能以某种方式恢复转储pg_dumpall -c而不会出现任何错误？

在执行 mysqldump 时，会跳过一些表，因为 mysqldump 将它们视为视图而不是表，尽管它们是 100% 的表。

所以对于某些表，它看起来像

-- Retrieving table structure for table services...
-- Sending SELECT query...
-- Retrieving rows...

对于一些：

-- Retrieving view structure for table users...
-- It's base table, skipped

我看到这个问题已经提到过几次了，但是没有解决方案。

显示创建表用户；

CREATE TABLE `users` (
  `id` int(10) unsigned NOT NULL AUTO_INCREMENT,
  `email` varchar(50) NOT NULL,
  `password` varchar(50) NOT NULL,
...
  PRIMARY KEY (`id`)
) ENGINE=InnoDB AUTO_INCREMENT=8915 DEFAULT CHARSET=utf8 

SHOW TABLE STATUS LIKE 'users' \G;

*************************** 1. row ***************************
           Name: users
         Engine: InnoDB
        Version: 10 …

我有一个测试数据库，我定期从 SQL Server 2008 R2 中的生产备份文件中恢复该数据库以获取新数据。与生产的存储过程相比，我们经常编辑\更改或更新测试数据库中的存储过程来测试数据！

是否只刷新\恢复表而不是存储过程？所以我不必将它们重新编辑回我需要的更改？

这两个数据库（生产和测试）都在一台服务器上。

我的数据库大小约为 5 GB，我们负担不起第三方工具。

创建备份时，SQL Server 会猜测（？）初始备份文件的大小。稍后，也许当它附加日志时，大小会被重新调整，有时会多次调整，直到达到最终大小。差异越大，备份所需的时间就越长。（与另一个备份相比，稍后不会调整大小）。示例：Database1（大小为 500GB，使用了 70GB 的日志）通过压缩进行备份。创建的 .bak 文件大小为 85 GB，一段时间后 CPU 使用率上升，我可以看到 .bak 文件重新调整为 136 GB，这种情况再次发生，直到备份的最终大小为 178GB到达。

当这些重新计算发生时，与同一台机器上的其他备份相比，以 MB/s 为单位的平均备份速度会降低。唯一来自附加和清除日志吗？还是因为数据库中使用的数据类型不同？意味着它们以不同的压缩率压缩，或者其他什么？

我来到这个话题，因为我知道我的备份需要大约 30 分钟，但现在即使数据库没有增长到其大小的 300%，也需要 1.5 小时。它仅增长了 30%。

使用等待统计数据，我可以看到除了 BackupIO 之外，我还在某个时候等待 CPU (SOS_SCHEDULER_YIELD)。

Machine Details:
VMWare 6.0 
32 GB of Memory (Max memory 28GB given to SQL Server)
2 logical CPU
Max Degree of Parallelism (1, it's a Sharepoint 2013)   
SQL Server 2014
Windows Server 2012 R2
running on an SSD Raid (5)

当然，我为运行备份的用户启用了即时文件初始化。

为了提高我们的 SQL Server 备份的性能，我们备份到多个备份文件。

• 在有关此主题的大多数博客文章中，他们都说要使用多个备份文件，但是，是否存在由于大量线程等待而导致文件过多而不是提高性能反而会导致性能下降的情况？
• 是否有任何基于例如服务器内核数的一般建议？更具体地说，我们的其中一台服务器显示 BACKUPIO并BACKUPBUFFER作为前 2 名违规者的等待统计数据。

我们正在使用 10 个备份文件备份一个大数据库（几个 TB），但我注意到服务器只有 4 个内核和 32 GB 的 RAM。我已将备份文件的数量更改为使用 4 个备份文件。我将在下周的下一个备份周期中看到它的进展情况，但与此同时，我试图根据服务器规格找到有关使用多少备份文件的任何建议。

我在文档中看到数据库备份工具分为四类：热备份、冷备份、物理备份和逻辑备份。

我理解冷备份和热备份最重要的区别是后者可以在数据库运行和接收读写查询时完成（并且结果将是一致的和原子的）。

但是，我怎么知道 mysqldump 有这个“热”方面还是“冷”方面？文档只是将它放在logical backup类别中，对此并不是 100% 清楚（是的，它似乎提到它在 mysqldump 过程开始时使用相同的数据库快照，这表明它绝对是一个热备份工具，但是只是想在这里仔细检查一下）。

这些表使用 InnoDB 引擎。