介绍

本文将探讨多余数据的概念.多余数据不是备份,但在您无法访问数据的主要方法的情况下,可以为您提供失败。

您选择在系统上实现复制的方式主要取决于您如何使用数据,您想要防范哪些故障,以及您的访问者如何与您的服务器实例互动。

◎ 被解雇

也许最常见的复制类型是 RAID . RAID 是独立磁盘的多余数组,这意味着在大多数配置中,磁盘以一种或另一种方式相互反映。

最基本的重复 RAID 实现是 RAID 1 数组. 这种类型的数组将一个磁盘反映在另一个磁盘上. 这意味着如果一个磁盘失败,另一个仍然可用于服务和写入数据。

这个例子也是一个很好的例子,说明为什么RAID和一般的冗余设置不是合适的备份。

RAID 复制是在低级别实现的,所以您不会在 DigitalOcean VPS 上控制 RAID 实现。

标签: 区块级解雇

提供冗余的另一种方法是镜像整个区块结构。 DRBD ,或分布式复制区块设备,是实现跨区块设备冗余的一种方式。

这可能看起来像一个镜像 RAID 阵列,在某些方面,它是。差异在于复制发生在哪里。在 RAID 中,冗余发生在应用程序级别以下。RAID 卡或 RAID 软件管理物理存储设备,并将应用程序呈现为一个单一的明显设备。

另一方面,DRBD是以完全不同的方式配置的。在DRBD设置中,每个硬件堆栈都被完全镜像化。应用界面也被镜像化。这意味着一个应用程序故障可以处理,因为有一个完全独立的机器与数据的副本进行工作。如果你的第一个服务器有电源故障,第二个服务器仍然会有效地工作。

SQL 复制

如果您的重要数据存储在 SQL 数据库中(MySQL、MariaDB、PostgreSQL 等),您可以利用一些内置的复制功能,这些功能可用于在主服务器故障时提供故障系统。

最基本的 SQL 复制类型是主奴隶配置. 在这种情况下,你有一个主数据库服务器,被称为主服务器. 这个服务器负责执行所有写作和更新. 来自这个服务器的数据被连续复制到一个奴隶服务器。

此设置允许您在多个机器中分配读取,这可以大大提高应用程序的性能。

虽然这种性能提升是一种优势,但您可能设置主奴隶复制的主要原因之一是处理故障。如果您的主服务器变得不可用,您仍然可以从您的奴隶服务器中阅读。

事实上,主奴隶复制是我们开始看到多余和备份如何相互补充的一个领域。在主奴隶配置中,您可以将数据从主人复制到奴隶。

要了解更多关于如何配置 MySQL 主奴隶复制,点击这里要了解如何完成 master-slave 复制与 PostgreSQL,请遵循本链接。

第二种形式的复制被称为Master-Master复制,这种配置允许两个服务器具有Master能力,这意味着每个服务器都可以接受写作和更新,并将更改转移到相反的服务器。

这也意味着,如果一个服务器出现故障,另一个服务器仍然可以接受请求,而配置更为复杂,但如果出现问题,故障转移比主奴隶解雇更为复杂,因为奴隶数据库不需要转化为主人。

此配置也可以与备份机制相结合,如果您将其中一个主服务器脱机,您必须保持一个静态的数据库,以便备份正常工作,因此您必须确保没有任何数据被修改或写入直到备份完成后。

分布式系统提供了传统冗余设置的许多优点。

另一个常见的 RAID 级别是 RAID 5,该 RAID 将数据分布在多个驱动器上,并在每个驱动器上写出数据的对等性,这意味着如果一个单一驱动器死亡,任何类型的交易都可以通过将其他驱动器上的对等性信息相结合来重建。

这提供了在磁盘上分发数据的不同方式,也可以处理单个磁盘故障。

分布式系统不必以硬件为基础,还有一些数据库和其他软件解决方案,旨在将分布式数据作为关键功能。

一个例子是Riack,一个分布式数据库。Riack节点都是相同的.不同部件之间没有主奴关系.存储在数据库中的对象被复制,因此在这方面有传统的冗余性。

然而,不是每个节点都包含整个数据库,而是数据以均匀的方式分布在节点之间,复制的对象被放置在不同的节点上,以便在硬件故障的情况下提供可用性。

在数据库中实现这一概念的另一个很好的例子是Cassandra,它基于与Riak相同的原则,但以不同的方式实现。

正如你所看到的,有许多选项,每一个都有其优点和缺点。这主要取决于你试图预见的问题,以及你认为系统的哪些部分是不可接受的故障。

您还应该能够从这一点看出,冗余设置不是备份的替代品。需要冗余系统始终运行并始终反映变化,可以很容易地允许数据从配置的所有点被破坏。

对于数据完整性和访问至关重要的应用程序来说,冗余和备份都是宝贵的,正确的实施将确保您的产品始终可供用户使用,重要数据永远不会丢失。