mysql 差异还原_MySQL差异转储? 还原的其他策略?

在MySQL主动/被动HA镜像环境中,主节点故障导致数据不一致。由于缺乏复制和事务日志,无法直接重播交易。现有夜间备份可用于恢复到过去的某个状态,但需要将次要节点的变化应用于主节点。问题在于如何在没有事务日志的情况下实现这种差异应用,以避免数据丢失。
摘要由CSDN通过智能技术生成

是否可以使用 `mysqldump` 生成差异转储 - 在两个数据库之间,或者理想情况下,在数据库和该数据库的转储版本之间生成?

Is it possible to generate a differential dump with `mysqldump` - between two databases, or, ideally, between a database and a dumped version of that database?

这是我遇到的问题 - 我有一个MySQL的主动/被动HA镜像,其中包含驻留在共享DRBD镜像上的实际DB数据(物理MyISAM文件,索引等)。 上周,主节点发生故障,DRBD主站从主节点转移到辅助节点,服务接管就像它应该的那样发生。

Here's the issue I've got - I have an active/passive HA mirror of MySQL with the actual DB data (the physical MyISAM files, indexes, etc.) residing on a shared DRBD mirror. Last week, the primary node failed and the DRBD master shifted from the primary to the secondary node, and service takeover happened like it was supposed to.

当然,已经对DRBD镜像的辅助副本版本进行了一系列更改,因此当主要版本重新启动时,它会接管DRBD卷,但双方都认为它们的一半"不同步"; (即 `StandAlone` )。

Of course, a bunch of changes have been written to the secondary copy's version of the DRBD mirror, so when the primary comes back up, it takes over the DRBD volume but both sides consider their halves "out of sync" (i.e. `StandAlone`).

所以,现在我的情况是数据库上发生了两组不同的交易:

So, now I have a situation where there are two divergent sets of transactions that have taken place on the database:

* 在主节点关闭且数据写入辅助节点时发生的情况;

* 自主节点重新启动并重新启动服务以来发生的情况; 他们从未同步过!

* That which happened in the time the primary node was down and the data was being written on the secondary;

* That which happened since the primary node came back up and took the services over again; they were never synchronised!

DRBD使我能够恢复到"一半"或"半"。 镜像(在其当前分区状态下)作为"主"的镜像。 修订,但可以看出,无论哪种方式都会导致我丢失数据。

DRBD gives me the ability to revert to either "half" of the mirror (in its current partitioned state) as the "master" revision, but as can be seen, either way causes me to lose data.

哦,是的:没有复制,也没有本地事务日志,所以没有重播的binlog。哎呀。_捂脸_

Oh, yeah: There was no replication and there were no local transaction logs, so there are no binlogs to replay. Oops. _facepalm_

当然,有夜间备份,因此我可以将数据库恢复到过去一年的任何~2 AM状态。

There are nightly backups, of course, so I can revert the DB to just about any ~2 AM state from the past year.

我想我要做的是恢复到次要"一半"数据库的版本。 现在(即在主要用户发生故障时发生的变化),然后尝试以某种方式将状态的变化从该点向前应用到主要的"半"的数据库的当前状态。累计。

I suppose what I'm looking to do is revert to the version of the database that's on the secondary "half" now (i.e. changes that happened while primary was down) and then try to somehow apply the changes in state from that point forward to the present state of the database on the primary's "half" cumulatively.

问题是,如果不重播事务日志,我不知道怎么会这样做。

The problem is, I have no idea how one would go about that without replaying transaction logs.

洞察得到赞赏,并提前感谢!

Insights appreciated, and thanks in advance!

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值