标签: database-restore

我是否总是必须删除然后创建数据库以从pg_dump文件还原它？如果我不删除数据库,则正在还原的数据将添加到数据库中的当前数据,即使某些寄存器已存在于数据库中(因此数据也是重复的).

我有一个实时数据库,从中删除了一些数据,我需要返回数据.我有一个已经在另一台机器上恢复的该数据库的最新副本.自备份以来,对实时数据库进行了无关的更改,因此我不想通过完全还原来清除实时数据库.

我需要的数据很小 - 只有十几行 - 但是那些十几行每个都有一些来自其他表的行和外键,而那些几行知道有多少行用外键指向它们,所以它会手工复原很复杂.

理想情况下,我能够告诉数据库的备份副本,以选择我需要的十几行,以及它们所依赖的所有内容的传递闭包,以及依赖于它们的所有内容,并导出那些数据,然后我可以导入到实时数据库而不触及任何其他内容.

这里最好的方法是什么？谢谢.

每个人都提到了sp_generate_inserts.使用它时,如何防止标识列搞乱一切？你刚刚开启IDENTITY INSERT吗？

我有sql server数据库文件(Mdf/Ldf),我想使用T-SQL命令或.net代码(C#或Vb.net)将它们转换为备份文件.

有什么建议.

thans

这与我在stackoverflow上看到的相关InnoDB修复问题略有不同.

假设我使用innodb_file_per_table = 1在MySQL 5.1数据库中恢复了以下内容:

db/tablename.ibd
innodb/ibdata1
innodb/ib_logfile0
innodb/ib_logfile1

我丢失了db/tablename.frm文件.我可以启动数据库服务器,但InnoDB抱怨:

110723 13:26:33  InnoDB: Error: table 'db/tablename'
InnoDB: in InnoDB data dictionary has tablespace id 5943,
InnoDB: but tablespace with that id or name does not exist. Have
InnoDB: you deleted or moved .ibd files?

我怎样才能重建FRM文件？

我正在尝试通过备份文件还原数据库，我使用的是PgAdmin III（PostgreSQL 9.1）。选择备份文件后，出现一个窗口，指示正在运行pg_restore.exe，然后PgAdmin没有响应，这已经是几个小时了（这不是RAM不足的问题）

可能是由于备份文件大小（500 MB），但是几天前我已经用300 MB的备份文件恢复了数据库，并且操作很顺利。顺便说一下，备份文件的格式（通过pg_dump创建）是“ tar”格式。

如果您有任何想法或需要更多信息，请告诉我。感谢任何人提供的帮助或指导。提前致谢。

我在Mac上进行了数据库备份，并尝试在具有ubuntu的计算机上还原该数据库。当我执行

psql -U uname -d dbname -f ~/dump_from_mac

我有很多错误消息，例如“无效命令\ N”和“关系'SomeTable'不存在”。我的问题与无法使用pg_dump将表复制到另一个数据库非常相似， 但是我不知道如何解决我的转储文件。我擦拭了Mac，无法进行新的转储。

cmd窗口中的以下命令

sqlcmd -S. -Usa -Ppass -dmaster -Q "RESTORE DATABASE [MYDATABASE] FROM DISK = 'D:\SQL Server\MYDATABASE.BAK' WITH FILE = 1, NOUNLOAD, REPLACE, STATS = 10"

显示以下输出：

10 percent processed.
20 percent processed.
30 percent processed.
40 percent processed.
50 percent processed.
60 percent processed.
70 percent processed.
80 percent processed.
90 percent processed.
100 percent processed.
Processed 32320 pages for database 'MYDATABASE', file 'MYDATABASE' on file 1.
Processed 7 pages for database 'MYDATABASE', file 'MYDATABASE_log' on file 1.

但是事实是，仅在整个还原 …

我正在将一个大型（~80GB）数据库从它的测试平台移到它的生产环境中。我们正在研究 Windows 服务器。这是我们第一次使用 MySQL，我们仍在学习预期的行为。

我们备份了数据

mysqldump -u root -p --opt [database name] > [database name].sql

这花了大约 3 个小时并创建了一个 45GB 大小的文件。它在一夜之间复制到它的新家，第二天早上，我使用 MySQL Workbench 启动了恢复。根据其日志，它运行

mysql.exe --defaults-file="[路径]\tmpc8tz9l.cnf" --protocol=tcp --host=127.0.0.1 --user=[me] --port=3306 --default-character-set =utf8 --comments --database=[数据库名称] < "H:\[数据库名称].sql"

它正在工作 - 如果我连接到实例，我可以看到数据库和它的一些表。

问题是，它似乎需要永远。我认为它会在与备份相同的 3-4 个时间范围内恢复，可能更快，因为它正在恢复到具有 SSD 驱动器的更强大的服务器上。

但是现在已经过了大约 36 个小时，因为恢复开始了，而且 DB 的大小显然是 30GB。随着它的进行，它似乎变得越来越慢。

现在它已经开始工作了，我不想打断它，所以我想我只需要等待。但供日后参考：这种蜜糖缓慢的恢复速度正常吗？下次我们需要恢复大数据库时，我们可以做些什么来改善问题？

我使用以下命令每天备份 postgresql 数据库

/usr/bin/pg_basebackup -D $outdir -Ft -x -z -w -R -v

现在我想在另一台服务器上恢复这个数据库。我使用了https://www.postgresql.org/docs/9.5/static/continuous-archiving.html#BACKUP-PITR-RECOVERY上的描述。

recovery.conf备份中包含的文件具有以下内容：

standby_mode = 'on'
primary_conninfo = 'user=postgres port=5432 sslmode=prefer sslcompression=1 krbsrvname=postgres'

文档中的下一步 (8.) 说要启动 postgresql。这会由于超时而导致失败：

3783 postgres: startup process   waiting for 0000000100000024000000B 

在原始服务器上我没有这个文件。是否可以在不使用任何 WAL 文件的情况下仅恢复 pg_basebackup 的状态？那么 recovery.conf 文件中应该有什么？

按照@JosMac 的建议，我用这个结果移动了 recovery.conf：

shaun2:/var/lib/pgsql/data # service postgresql start
Job for postgresql.service failed because the control process exited with error code. See "systemctl status postgresql.service" and "journalctl -xe" for details.
shaun2:/var/lib/pgsql/data # service postgresql status
â …

我在网上搜索了一些解决方案并遇到了几篇文章，但这些步骤都不适合我，因为它们需要一个已经配置的数据库，而且它们只是恢复备份。我想我首先需要 .mdf 文件，这样我就可以按原样重新创建数据库，然后我可以通过 .abf 文件更新它，有人能指出我正确的方向吗？