NoSQL-Master-Slave Replication 主从复制

翻译内容：

NoSQL Distilled 第四章 Distribution Models

作者简介：

本节摘要：

各位好，今天我们主要讨论有关分布模型中复制（Replication）的内容,今天的内容主要说主从复制（Master-Slave Replication）。复制在分布式存储中是一个很重要的内容，知道了有关复制及分片，你也就知道了分布式存储的底层原理。

4.3. Master-Slave Replication 主从复制

With master-slave distribution, you replicate data across multiple nodes. One node is designated as the master, or primary. This master is the authoritative source for the data and is usually responsible for processing any updates to that data. The other nodes are slaves, or secondaries. A replication process synchronizes the slaves with the master (see Figure 4.2).

在主从分布的情况下，你把一份数据复制到多个节点。其中一个节点作为主节点（master）。这个主节点是数据的权威（译者曰：你可以认为就是这个节点负责调度，数据都得经过它的手，所以它牛逼啊）同时通常也负责数据的更新。（译者曰：master就做两件事情：权威和数据更新操作）。除了主节点之外的其它节点为从节点（slave）或者叫老二（secondaries）。复制（replication）过程就是把数据从主节点同步到从节点的过程。

Figure 4.2 Data is replicated from master to slaves. The master services all writes; reads may come from either master or slaves.

图4.2 数据从master复制到slave。master处理所有的“写”操作；而“读”数据可以从master上读也可以从slave上读。

Master-slave replication is most helpful for scaling when you have a read- intensive dataset. You can scale horizontally to handle more read requests by adding more slave nodes and ensuring that all read requests are routed to the slaves. You are still, however, limited by the ability of the master to process updates and its ability to pass those updates on. Consequently it isn’t such a good scheme for datasets with heavy write traffic, although offloading the read traffic will help a bit with handling the write load.

在需要频繁的读取数据集的情况下，主从复制可以通过扩展（scaling）来提高读取性能（译者曰：这里的扩展就是增加从节点）。你可以通过增加更多的从节点的方式，通过这种水平扩展的方式，来handle更多的读取请求（request）。并且可以把所有的读取request都交给从节点来处理。（译者曰：或者可以说确保把读取请求路由到从节点）

但，由于主节点既要负责处理写入请求，又要负责把数据同步到从节点。自然这种“主从复制”模式对于那种频繁写入的场景并不是很适合，虽然这种模式它是分流了一部分的read 请求到从节点，看起来好像为写入请求有所帮助。（译者曰：“对写入请求有帮助”只是相对于过去的一台机器既要处理写又要处理读的情况。但本质上master还是显得有点疲惫，因为写操作得它自己一个人来搞，并没有分摊到从节点上。）

A second advantage of master-slave replication is read resilience: Should the master fail, the slaves can still handle read requests. Again, this is useful if most of your data access is reads. The failure of the master does eliminate the ability to handle writes until either the master is restored or a new master is appointed. However, having slaves as replicates of the master does speed up recovery after a failure of the master since a slave can be appointed a new master very quickly.

master-slave复制的第二个优点就是“读取故障恢复能力”（译者曰：什么意思呢？就是说主节点挂了，从节点就去扛）：主节点挂了，从节点依然可以handle读取请求。重要的事情说三遍，对于大部分的数据访问都是读取的场景是非常有用的，非常有用的，非常有用的。

主节点挂了自然就不能提供写入能力了，直到她恢复了或者一个新的master被选出来。然而，拥有“从节点作为主节点的备份”自然是极好的，因为即使主节点挂了，我们也可以非常迅速的就从茫茫从节点中选出一个新的主节点来。（译者曰：因为从节点就是主节点的备份，他们实在是一模一样啊）

The ability to appoint a slave to replace a failed master means that master- slave replication is useful even if you don’t need to scale out. All read and write traffic can go to the master while the slave acts as a hot backup. In this case it’s easiest to think of the system as a single-server store with a hot backup. You get the convenience of the single-server configuration but with greater resilience—which is particularly handy if you want to be able to handle server failures gracefully.

这种快速选出新的master的能力意味着我们的“主从复制”即使没有提高读取性能的能力也会变得很有用。（译者曰：就这一点“高可用”就够了）。当我们的从节点专心就做备份这一件事情的时候，我们就可以把所有的读取和写入都交给master来做。这样的做法是不是会让你很容易联想到“拥有热备份的单服务器”的方案。（译者曰：是不是感觉很优雅，变回单机是不是感觉一下子很熟悉）。这种方案让你既拥有了单机配置的简单又拥有强大的故障恢复能力——如果你希望优雅的handle服务器故障，此方案值得拥有！

Masters can be appointed manually or automatically. Manual appointing typically means that when you configure your cluster, you configure one node as the master. With automatic appointment, you create a cluster of nodes and they elect one of themselves to be the master. Apart from simpler configuration, automatic appointment means that the cluster can automatically appoint a new master when a master fails, reducing downtime.

现在我们来摆选主节点的这个事情。主节点可以手动配置指定，也可以是通过自动选举产生。手动指派的意思就是在你配置集群的时候，就配置一个node作为主节点（master）。自动指派就是指在你create集群了以后，他们就热闹的开始选举了，最后在茫茫node中选出一个master来。经过简单的配置后，就可以在master挂掉的时候然后自动选举出一个新的master。这大大缩短了集群的“罢工”时间！

In order to get read resilience, you need to ensure that the read and write paths into your application are different, so that you can handle a failure in the write path and still read. This includes such things as putting the reads and writes through separate database connections—a facility that is not often supported by database interaction libraries. As with any feature, you cannot be sure you have read resilience without good tests that disable the writes and check that reads still occur.

现在再回来说“读取的故障恢复”这事。要想让读取具备故障恢复能力，那么我们就要把写在我们的应用程序里边的“读”的path和“写”的path分开，也就是他们的path必须是不同的，这样你的写操作出现故障时，我们的读取依然坚挺。（译者曰：这里的path，你可以理解为hdfs api里边的那个path。或者直接可以理解为new File(String path)这个里边的path。）这个读写分离怎么搞呢？就是要你通过两个独立的分开的数据库connection来分别提供读和写。这样的能力大部分的数据库交互库都是不提供的（译者曰：过去都是单机版的，自然不提供这些了。译者所在公司最近恰好也在搞分布式存取，也是把我们常用的某个数据库改为支持分布式，并提供统一的数据访问）。当然了，你要开发这样的支持，其实和开发其它的功能是一样的，也是要通过不断的测试来确保这个故障恢复能力的有效性。我们可以把写操作禁用了，然后再试试看是不是能正常的读取。

Replication comes with some alluring benefits, but it also comes with an inevitable dark side—inconsistency. You have the danger that different clients, reading different slaves, will see different values because the changes haven’t all propagated to the slaves. In the worst case, that can mean that a client cannot read a write it just made. Even if you use master-slave replication just for hot backup this can be a concern, because if the master fails, any updates not passed on to the backup are lost. We’ll talk about how to deal with these issues later

(“ Consistency,” p. 47).

复制用起来是那么迷人，但她也是有阴影面积的，那就是——不一致性。比如，有可能不同的客户端访问不同的从节点，最后得到不同的value。因为有可能master的同步工作正在做，同步了一部分节点，另外一部分节点还没有同步完。有一种最尴尬的情况，就是一个客户端刚刚写入一条数据，然后他立马就去读自己写入的这条数据，结果没读到。即使你使用主从复制仅仅是为了做个热备份也会遇到这样的问题，因为如果主节点挂了，那么任何的更新将不会被同步到从节点上去。我们将在稍后的章节中讨论如何解决这一问题。

以上！下期我们说有关“对等复制”的内容！

附：纠误清单（以下错误为用户或译者自己发现）

1、在Modeling for Data Access 的这篇中，我们的demo code少写了一行对orderid的引用，现奉上正确内容：

# Customer object { "customerId": 1, "customer": { "name": "Martin", "billingAddress": [{"city": "Chicago"}], "payment": [{"type": "debit","ccinfo": "1000-1000-1000-1000"}], "orders":[{"orderId":99}] 那篇文章中漏了这一行 } } #Orderobject { "customerId": 1, "orderId": 99, "order":{ "orderDate":"Nov-20-2011", "orderItems":[{"productId":27, "price": 32.45}], "orderPayment":[{"ccinfo":"1000-1000-1000-1000", "txnId":"abelif879rft"}, "shippingAddress":{"city":"Chicago"} } }

文章地址：http://mp.weixin.qq.com/s?__biz=MzA5MzQ2NTY0OA==&mid=503312426&idx=1&sn=2a1320e0d99d312bddd911e8fd5bc95b#rd

2、在上一期的内容（Sharding）中，我们说好的为您提供bigtable中的一段内容，但没有为您提供，现奉上：

在有的情况下，你把聚合放在一起是有用的，如果你认为它们会被一块依次读取的话。在谷歌的Bigtable的论文就提到过他们对于这种情况的做法。他们把域名颠倒过来作为key然后进行排序存储。这样对于多个网页被同时访问的那种情况，读取性能就会被提升。以下我们找到了谷歌Bigtable paper 中关于这个做法的片段： Bigtable maintains data in lexicographic order by row key. The row range for a table is dynamically partitioned. Each row range is called a tablet, which is the unit of dis- tribution and load balancing. As a result, reads of short row ranges are efficient and typically require communi- cation with only a small number of machines. Clients can exploit this property by selecting their row keys so that they get good locality for their data accesses. For example, in Webtable, pages in the same domain are grouped together into contiguous rows by reversing the hostname components of the URLs. For example, we store data for maps.google.com/index.html under the key com.google.maps/index.html. Storing pages from the same domain near each other makes some host and domain analyses more efficient.

文章地址：http://mp.weixin.qq.com/s?__biz=MzA5MzQ2NTY0OA==&mid=503312438&idx=1&sn=047c4f3ea03d390d6a1804a7b232112a#rd