PostgreSQL Replication之第一章理解复制概念一

本是古典何须时尚 2022-12-28 08:18 91阅读 0赞

在本章中，将会介绍不同的复制概念，您会了解哪些类型的复制对哪一种实用场景是最合适的。 在本章的最后，您将能够判断某个概念在各种情况下是否是可行的。  
我们在本章将介绍以下主题：  
• CAP理论  
•复制的物理限制  
•为什么延迟有影响  
•同步和异步复制  
•拆分和复制  
在我们使用PostgreSQL实际工作之前，我们将引导您完成一些非常基本的与复制相关想法和事实。

## 1.1 CAP理论和物理限制 ##

您可能会问，为什么一个理论可以在一本书这样一个突出的地方被发现，这被认为是非常实用的。那么，有一个很简单的理由：一些商业数据库厂商的一些看起来很好看的市场方案留给您的印象是一切皆有可能，是没有任何严重限制的，容易做的。这并不是事实；每一个软件供应商必须处理这些限制。没有任何办法绕过自然规律，市场并不能克服自然。  
在本章中，您将被介绍到所谓的CAP理论。在解决一些不能被变成现实的需求的情况下，理解这一理论的基本思想是必不可少的。

### 1.1.1 理解CAP理论 ###

在我们深入到细节之前，我们必须讨论CAP的实际意义。CAP是一下三个特征的缩写：  
Consistency(一致性):该特征表明集群中的所有节点在同一时刻是否看到了相同的数据。  
Availability(可用性):该特征表明是否所有的请求都可以收到一个返回结果。用户是否可以认为一个集群中的所有节点是可用的？在两台机器之间拆分数据或状态信息。发出一个请求，机器1有一部分数据，机器2拥有剩余部分的数据。如果任何一台机器出现故障，并不是所有的请求都可以被满足，因为并不是所有的数据或状态信息在任何一台机器上都是可用的。  
Partition tolerance(分区容忍性):该特征表明在工作过程中如果有任意的消息丢失，系统是否能够继续工作。当一个系统不再接受访问时(考虑一个网络连接失败)，就会发生一个网络分区事件。考虑分区容忍性的一个不同的方法是把它作为消息传递。如果一个专用系统不能再发送/接收消息到/从其他系统，它已被有效地从网络中除去。

为什么这前三个要点与普通用户有关呢？坏消息是一个复制(或分布)系统只能同时提供2/3的特征。  
在理论上是不可能同时提供一致性，可用性，分区容忍性。正如您将在本书后面看到的，这对系统的的安全和可用的布局有显著的影响。根本没有如此简单的事情作为解决所有复制相关的问题。当您规划一个大规模的系统，您可能要想出不同的概念去满足您的需求，这些概念取决于您的需要。  
\[PostgreSQL，Oracle，DB2等等将为您提供Cap，而NoSQL系统，例如，MongoDB 或者 Cassandra 将为您提供cAP。这就是为什么NoSQL通常被称为是最终一致的。\]

### 1.1.2 为什么光速重要 ###

光速不仅是一个理论问题，它确实会对您的日常生活产生影响。更重要的是，它对您找到适合您集群的解决方案有重要的含义。  
我们都知道，宇宙的极限速度是光速。那么，为什么要在乎？好吧，让我们做一个简单的心里实验。让我们假设我们的数据库服务器以3GHz的时钟速度运行。  
在您的CPU的一个时钟周期内光可以走多远的距离？如果您计算的话，您会发现光在每个时钟周期(纯真空)走的距离为10厘米。我们可以假设在CPU内的电信号会比在真空中的光的幅度较慢。核心思想是：一个时钟周期10厘米？一点都不多。  
为了我们的心理实验，现在让我们考虑不同的距离：  
•两个CPU之间的距离  
•您的服务器到隔壁其他服务器的距离  
•您在欧洲中部的服务器到中国服务器的距离  
考虑到在电路板上的一个CPU核的大小，您可以假设从CPU的一个部分发送一个信号(尽管他没有光的速度快)到其他部分相当地快。计算已经在您的CPU的一级缓存中的两个数据的和它根本用不了一百万个时钟周期。

但是，如果您必须从一个服务器发送一个信号到其他服务器发生了什么？您可以安全地假设从服务器A发送一个信号到隔壁的服务器B需要花费很长时间，因为电缆是比较长的。通常情况下，它超过10厘米。除此之外，网络交换机和别的网络组件将产生额外的延迟。(此处电缆的长度不是电缆的带宽)  
\[这里我说的是电缆的长度，而不是关于它的带宽。\]  
从欧洲发送消息(或事物)到中国，通常情况下和发送一些数据到隔壁的服务器相比要耗费更多的时间。再次，重要的是，这里的数据量和所谓的延迟时间并不相关。

### 1.1.3 远程传输 ###

让我尝试通过给出一个非常简单的例子来解释延迟的概念。假设您是欧洲人，您在发送一封信到中国。您会很容易接受这个事实：您的信的大小并不是这里的限制因素。不论您的信是两页或二十页，并没有任何区别；到达目的地所花费的时间是基本相同的。此外，如果您同时发送一封，两封，十封信也是没有区别的。考虑到合理的信的数量，运送东西到中国的飞机(带宽)的大小通常不是问题。但是，所谓的往返很可能是一个问题。如果您依赖来自中国信件的响应来继续您的工作，您很快就会发现自己等了很久。

### 1.1.4 为什么延迟有影响 ###

同样的概念也适用于复制(replication):如果您从欧洲发送数据块到中国，您应该避免等待响应。如果两台在同一个机架上的服务器之间发送数据块，您可能可以等待响应，因为您的电信号会足够快使信号即使返回。  
\[本节中描述的延迟的基本问题不是PostgreSQL所特有的。相同的概念和物理限制适用于所有类型的数据库和系统。和以前一样，这个事实有时候在闪亮的商业营销论文里静静地被隐藏和被忽视。尽管如此，物理定律是不变的。这适用于商业和开源软件。\]  
最重要的一点，您必须记住的是：在复制环境中，带宽不总能解决性能问题。在许多设置中，延迟至少和带宽一样重要。

## 1.2不同类型的复制 ##

现在，您已经完全地理解了物理和理论的局限性，可以开始学习不同类型的复制了。

### 1.2.1 同步和异步复制 ###

我们可以做的第一个区分是同步复制和异步复制的区别。这是什么意思呢？假设我们有两台服务器，希望从一台服务器(the master)复制数据到第二台服务器(the slave)。下图说明了同步和异步复制的概念：  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2FzbWFydGtpbGxlcg_size_16_color_FFFFFF_t_70]  
我们可以使用一个简单的事务如下所示：

BEGIN:
    INSERT INTO foo VALUES ('bar');
    COMMIT;

在异步复制的情况下，事务被提交到master之后数据才可以被复制。换句话说，slave从不会超前master,就写操作而言，通常滞后于master一些。此延迟(delay)被称为滞后性(lag)。  
同步复制强制执行了较高的一致性规则。如果您决定使用同步复制(如何做到这一点实际上将在第五章中讨论，建立同步流复制)，系统必须确保通过事务写入的数据至少事务同时在两台服务器上提交。这意味着：slave 不滞后于master,而且终端用户在两台服务器上看到的数据是一致的。  
\[有些系统也将使用仲裁服务器来决定。因此，它不是总是关于只有两个或者更多的服务器。如果一个仲裁服务器被使用，超过一半的服务器必须同意集群内的行动。\]  
理解复制和数据丢失  
当一个事务从master复制到slave,很多事情必须考虑到，尤其是当涉及到像数据丢失的事情。  
假设我们正在以以下方式异步复制数据：  
事物发送到master。  
事物提交到master。  
在事物发送到slave之前，master宕机。  
slave永远都不会收到这个事务。  
在异步复制的情况下，有一个窗口(滞后)，在滞后窗口期间数据会丢失。滞后窗口的大小因设置类型的不同而不同。它的大小非常短(几毫秒)或非常长(几分钟，几小时，几天)。一个重要的事实是：数据可能丢失。一个小的滞后只会是数据丢失的可能性较小，但，任何大于零的滞后都容易导致数据丢失。

如果您想确保数据永远不丢失，您必须切换到同步复制。正如您在这个章节已经看到的，一个同步事务是同步的，因为如果事物提交到了两台服务器它是有效的。

考虑性能问题  
正如您在关于光速和延迟章节所了解到的，通过网络发送不必要的消息的开销是昂贵的和费时的。如果一个事务采用同步的方式复制，PostgreSQL必须确保数据到达第二个节点，这样就会导致延迟问题。  
在许多方面，同步复制比异步复制要昂贵很多，因此如果这种消耗确实需要和调整，人们应该三思而后行。(只在需要的时候使用同步复制)  
\[当真的需要的时候，才使用同步复制。\]

### 1.2.2单master复制与多master复制 ###

各种复制设置的第二种分类方法是单masster复制和多master复制。  
单master意味着写操作只能发送到一个服务器，该服务器分配数据到内部设置的slave上。slave只能接收读操作但是不会接收写操作。  
相对于单master复制，多master复制允许写操作发送到所有集群内部的服务器。下图显示了系统如何在一个概念层面工作：  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2FzbWFydGtpbGxlcg_size_16_color_FFFFFF_t_70 1]  
可以写到集群内部的任何节点听起来像一个优点，但它不是一个必须的优点。其原因是多master复制给系统添加了不少复杂性。在只有一个master的情况下，哪个数据是正确的，数据会流向哪个方向是非常清楚的，而且在复制过程中很少有冲突。多master复制是完全不同的，写操作可以同时被发送到多个节点，集群必须非常清楚冲突并妥善地处理它们。使用锁来解决这个问题是一个可供选择的方法，但这种方法会产生其自身的问题。  
\[请记住，解决冲突的需要会产生网络通信，并且这可以瞬间变成由延迟引起的可扩展性问题。\]

### 1.2.3 逻辑复制与物理复制 ###

分类复制的另一种方式是逻辑复制和物理复制之间进行的区分。  
不同是细微的，但非常重要。物理复制指系统将移动数据到远程服务器。  
因此，如果有东西被插入。远程服务器将获取数据的二进制格式，而不是通过SQL。  
逻辑复制意味着一个变化，相当于即将到来的数据被复制。  
让我们看一个例子，充分理解两者的差异：

test=# CREATE TABLE t_test (t date);
    CREATE TABLE
    test=# INSERT INTO t_test VALUES (now())
    RETURNING *;
    t
    ------------
    2013-02-08
    (1 row)
    INSERT 0 1

我能看到这里执行了两个事务：第一个事务创建了一个表。一旦这个完成后，第二个事务向表里增加了一个简单的日期并提交。  
在逻辑复制的情况下，改变将被以逻辑形式发送到某种队列，因此系统不发送普通的SQL，但也许是如下的东西：

test=# INSERT INTO t_test VALUES ('2013-02-08');
    INSERT 0 1

注意，函数调用已被替换为实际的值。如果slave重新计算now()函数，这将是一个巨大的灾难，因为在远程服务器的日期可能是一个完全不同的日期。  
\[有些系统把基于语句的复制作为核心技术。例如：MySQL使用一个所谓的bin-log来复制,这实际上并不是二进制，而是某种形式的逻辑复制。\]  
物理复制将工作在一个完全不同的方式：不是发送一些SQL(或其它)，这在逻辑上是等价的，系统会发送PostgreSQL内部所做的二进制替代物。  
下面是一些二进制替代物，我们的两个事务可能被触发(到目前为止，还不是一个完整的列表):  
添加一个8k的块到pg\_class并插入一条新的记录(表明表是目前的状态)。  
添加行到pg\_attribute存储列名。  
执行这些表内的各种变化。  
记录提交状态等等。  
物理复制的目标是在相同的物理级别创建一个系统的副本。这意味着在所有的服务器上相同的数据将在您的表的相同的地方。在逻辑复制的情况下，但是不论内容是否在相同的地方，没有任何不同，内容应该是相同的。

何时使用物理复制  
物理复制使用起来非常方便，尤其是容易建立。当目标是创建系统的相同副本(创建一个备份后，简单地扩展)时，物理复制被广泛使用。  
在许多设置中，物理复制是标准的方法，该方法把尽可能最低的复杂性暴露给终端用户。它是理想的向外扩张数据的方法。  
何时使用逻辑复制  
通常逻辑复制的设置有点难，但它提供了更大的灵活性。当涉及到升级现有的数据库时，它也是特别地重要。物理复制完全不适合版本跳跃，因为您不能简单地依靠每个版本的PostgreSQL具有相同的磁盘布局的事实。存储格式可能会随时间而改变，因此二进制复制显然是不适合从一个版本跳跃到另一个版本的。  
逻辑复制允许解耦合数据存储方式和数据传输，复制方式。通过使用中性协议，该协议并不和特定版本的PostgreSQL绑定，很容易从一个版本跳跃到另一个版本。

PostgreSQL Replication系列翻译自PostgreSQL Replication一书  
https://www.cnblogs.com/songyuejie/p/4743307.html

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2FzbWFydGtpbGxlcg_size_16_color_FFFFFF_t_70]: /images/20221120/d10c4a996ced4c7f878ad8c0d3f3271f.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2FzbWFydGtpbGxlcg_size_16_color_FFFFFF_t_70 1]: /images/20221120/84f6c848ffd84151acfbec2497dc18b6.png