我不是mysql专家,但似乎没有明显的方法可以做到这一点。我会解释我想要什么。假设我正在进行数据迁移,它将更新某些表中的一些行。
我希望能够进行备份,执行迁移脚本,并自动获得撤销脚本。
我不认为这是不可能的,因为关系数据库管理系统已经将所有更改存储在日志中以供事务处理(例如,mysql有--log-bin选项),而且他们已经知道如何恢复它们(因为它们可以回滚事务)。因此,也许可以提取和使用这些数据来创建用于迁移的撤销脚本?
编辑。
好吧,感谢其中一个答案,我发现mariadb实际上部分支持我想要的东西。这个特性叫做闪回。它实际上是在做我建议的事情--通过binlog将插入转换为删除。因此,我所缺少的是即将到来的对DDL语句的闪回支持,并且只对一个事务进行闪回。
发布于 2018-08-17 16:17:26
RDBMS日志更改的主要原因是崩溃恢复。除非设置逻辑复制,否则更改通常以特定于供应商的格式存储,而不是作为一系列sql语句存储。回滚事务涉及将数据还原到以前的状态,而不是生成和发出另一个sql语句。在我看来,为随机事务生成这样的语句似乎不是不可能的,但至少是模棱两可和不切实际的。编写“反向”查询的方法不多,一旦任何新的事务提交,该查询就会变得无效。
例如,
BEGIN TRANSACTION;
DELETE FROM table1;
ROLLBACK;不会生成一堆INSERT语句。大多数关系数据库管理系统都不会对数据文件进行任何更改,因此将立即执行ROLLBACK。
如果您不想编写撤消迁移脚本的效果的sql脚本,而且您的数据库不支持闪回(如甲骨文或某种程度上的MariaDB)或快照备份(如Server),则除了备份/还原之外,没有其他替代方法。您可以通过使用zfs文件系统或商业产品(如NetApp ),将备份/还原时间缩短到秒,甚至对于大型数据库也是如此。
发布于 2018-08-16 10:18:52
我希望能够进行备份,执行迁移脚本,并自动获得撤销脚本。
为什么?
如果迁移失败得非常严重,以至于它将被放弃,那么恢复数据库的备份。这是保证你回到起点的唯一方法。
我不知道如何创建一个“撤销”脚本,但是,即使你可以,也不能保证它会起作用,在它的“恢复”过程中可能会失败,让你处于一个更糟糕的境地,介于最后一个好状态和迁移失败的点之间,但你不能完全确定它在哪里。从那时起,你就抓着吸管,试着收拾烂摊子。
更好地(/更容易/更可靠)将“损坏”数据库扔到bin中并从备份中恢复它。
https://dba.stackexchange.com/questions/215029
复制相似问题