问题标签 [crash-recovery]

我们有一个应用程序，作为其要求之一，它将采用任意 3rd 方插件，加载它们，并与我们自己开发的应用程序一起运行它们的 UI。我们一直在将这些 3rd 方插件加载到他们自己的 AppDomain 中以进行隔离，一切正常。

直到其中一个插件因未处理的异常而崩溃。在这种情况下，整个应用程序都会崩溃，即使真正受到影响的只是我们的“额外”工具窗口之一。

理想情况下，我们希望通过某种方式来处理“未处理”异常，卸载损坏的 AppDomain，然后重新加载它。 问题是我们在事件处理程序中找不到未处理异常的机制，我们可以将异常标记为“已处理”。此外，由于插件有自己的 UI 组件和自己的用户交互集，因此很难将我们与插件的交互“包装”在 try/catch/finally 块中。

是否有任何框架/编程库/模式可以解决这个问题？我们可以很好地做插件； 我们需要帮助的是当不同 AppDomain 中的代码意外失败时保持应用程序处于活动状态。

我有一个基本上是序列号生成器的系统。

序列号生成器有两个主要的设计要求（在容错方面）：

1. 签发的所有序列号必须是唯一的（不得重复）
2. 如果序列号生成器崩溃，它需要一种从中断处重新启动的方法（如果需要，可以在从崩溃中恢复时跳过几个序列号，以确保满足要求 #1）

可以假设序列号是按顺序发出的（1、2、3、4等）

我第一次尝试解决这个问题是让序列号生成器通过附加到单个日志文件来记录每个有问题的序列号。这样，如果它崩溃了，它只是从发布的最后一个序列号中获取，然后继续它的快乐方式。

挑战如下：

那么，以下日志记录方法的优缺点是什么：

1. 有一个附加的日志文件，并以特定大小为上限
2. 有两个日志文件，都没有附加。第一个日志文件始终包含最近发布的序列号，第二个文件包含第二个最近发布的序列号。日志文件以跷跷板方式写入（即所有偶数序列号最终都放入日志文件“A”，奇数序列号放入日志文件“B”）。最终结果是你总是得到最后两个序列号（并且没有更多），磁盘空间的使用很小，如果序列号生成器在记录最近的序列号时发生崩溃，那么'最近的文件可能已损坏。由于我们在另一个日志文件中也有第二个最近的序列号，我们可以检测到崩溃，并从这个“第二个最近的”序列号重新启动序列号生成器，+2

在序列号生成器无法判断“最新”或“第二个最新”日志文件中的哪个是损坏的崩溃场景中，始终从未损坏的序列号重新启动崩溃的生成器应该是安全的 + 2.

选项 1 实现起来稍微简单一些，但选项 2 使用的磁盘空间更少，而且看起来更智能。

在设计一个可以通过足够的日志文件可靠地从崩溃中恢复的系统方面，我是否遗漏了什么？

我的记事本++ 在关闭并重新启动程序时尝试重命名文件后发生崩溃。

根据 .dmp 信息，它在未经许可的情况下读取/写入虚拟内存。

以下是一些有助于界定问题的附加信息

• 问题的根源不是文件名（替换旧的不起作用）
• UAC 不会出现此问题
• 我目前正在处理没有“奇怪”附加内容的全文文件
• 我看不到我正在使用的版本的文档参考，但安装程序建议使用 5.9.3（dmp 文件具有相同的版本号参考）

我的问题是这样的：

除了重新安装之外，是否还有其他方法可以解决此问题，例如，我能否找到一个缓存系统/机制来帮助我确定 notepad++ 加载的内容（特别是文件引用）。我部分要求快速解决问题，部分要求更多地了解如何处理这些操作。

提前致谢！

编辑：我似乎做了标题....完全错了。如果 mod/adm 可以修复它或告诉我如何帮助。

以下是我对日志文件组的理解。

每当插入/更新 innodb 表时，这些表将在 innodb_log_buffer_size 中捕获。如果 innodb_log_buffer_size 已满或到了将其刷新到磁盘的时间，它们将被写入 innodb_log_files，这些文件以组的形式维护并同时提交到表空间中。

现在我的问题是，为什么我们不应该让 innodb_log_files 的总大小超过 innodb_buffer_pool 的大小，为什么我们要写入这些日志文件，尽管我们正在将它们刷新到磁盘......？

我无法通过网络得到正确的解释，至少我无法理解。请给我一些更好的解释。

真的提前谢谢了。问候， UDAY

我的 iSeries ILE 程序因未提交的更改而崩溃。现在我希望使用 ENDCMTCTL 结束提交控制（再次启动程序，程序自己启动提交控制），但它失败并显示消息：

有没有办法以正确的方式回滚/提交更改并结束提交控制？我更有经验的同事建议只退出并开始新的会话。

编辑

我已经尝试过 WRKCMTDFN 和其中的所有操作，但都没有成功。强制回滚和强制提交失败并显示消息：

为了清楚起见，我的问题与语言/操作系统无关（独立）。

我正在开发一个程序（支持许多操作系统，目前用 Golang 编写）接收许多数据块（如数据块流）并按顺序将其全部写到预先指定的位置（pos >= 0）文件。只有 1 个进程和 1 个线程访问该文件。我使用常规的写入函数，它在内部使用写入系统调用（取决于它运行的操作系统），而不是缓冲 IO。

假设在我的程序正在编写时，突然系统崩溃（最严重的崩溃类型：电源故障）。

当系统重新打开时，我需要验证有多少块完全写入 HDD。(*)

我的程序写入的 HDD 只是今天的普通台式机或笔记本电脑 HDD（不是某些高端服务器中的一些花哨的（带电池后备的））。

假设在传输到 HDD 和从 HDD 读取期间发生位损坏的可能性非常小，并且可以忽略不计。

我的问题是：

1. 我是否需要对所有写入的块进行校验和以验证 (*)？

2. 还是我只需要检查并确认第 n 个块是正确的，并假设它之前的所有块 (0 -> n-1) 也是正确的？

   2.1 如果 2. 足够了，这是否意味着任何操作系统的 FS 都可以保证顺序写入顺序（随机写入仍然可以重新排序）？

3. 我的恢复方式是否依赖于与许多防崩溃数据库中看到的仅附加日志文件相同的原则？

我有一个 MapReduce 作业，我使用job.waitForCompletion(true). 如果一个/多个 reducer 任务在作业执行期间被杀死或崩溃，则整个 MapReduce 作业将重新启动，并且映射器和 reducer 将再次执行（文档）。以下是我的问题：

1] 我们能否在作业开始时知道作业是重新开始还是由于上一次运行中的某些故障而重新启动？（这使我进入了第二季度）

2] 计数器可以提供帮助吗？如果某些任务失败，计数器的值是否会被保留，从而导致整个作业重新启动？

3] Hadoop 是否提供任何内置检查点方法来跟踪先前的计算并帮助避免在失败/崩溃之前执行映射器和化简器完成的相同计算？

抱歉，如果问题的措辞不清楚。谢谢您的帮助。

我在网上搜了一下，STEAL和FORCE定义如下

FORCE or NO-FORCE：事务的所有更新都应该在事务提交之前强制到磁盘吗？

此外，有人告诉我

在所有日志记录都写入稳定存储之前，不会认为事务已提交

那么 WAL 与 FORCE 方法有什么不同呢？我觉得在这两种情况下，都必须在提交事务时将更改刷新到磁盘......

我正在构建一个电子应用程序，如果发生崩溃，它必须重新加载渲染进程窗口。

目前我可以从主进程重新启动应用程序

但我无法检测到窗口崩溃。我尝试使用

但是当我使进程崩溃时，事件并没有生成。

要使我尝试的过程崩溃：

• 调用process.crash()
• 使用所有可用内存。

两种方式都成功地使进程崩溃，但同样，我找不到检测它的方法。

当检测到崩溃时，我还尝试从渲染进程中使用window.onerror(...)并通过 IPC 向主进程发送一条消息，但这似乎也不起作用。

我正在将 OpenEBS 与 Jiva 一起使用。我在具有 3 个副本的 OpenEBS 上运行 MySQL pod。我的数据库约为 10GB，实际卷大小约为 30GB

在我丢失一个副本后，新的副本会出现。假设它立即开始复制数据；1）我怎么知道重建已经完成并且可以肯定地说？2) 每 10 GB 数据在 AWS（使用 EBS 卷）上完成副本重建的平均时间是多少？