hadoop原理巧用到异地机房双活

为什么要考虑hadoop集群异地双活？因为我们一般集群的建设基本上都是部署在同一个地方，为了保证公司业务24小时不间断服务，所以必须要考虑集群的高可用，而我们常见的高可用一般是给A集群搞个灾备集群B集群，A、B集群不会再同一个机房，A、B集群的数据同步依赖于hadoop自身提供的工具distcp，那么discp有什么缺点呢。

1. 长时间占用yarn资源

2. 一般只同步重要的部分数据（这一点其实没毛病）

3. 两个集群必须所有节点必须网络畅通

4. 天级别数据延迟，因为我们可能一天24小时都在同步数据，一般是一天做一次数据同步，也就意味着数据存在天级别丢失的风险

为了解决这个问题，我们来研究下hadoop原来，看看有没有什么搞头

这个图大家一看应该很容易明白，网上也很多人讲这个，我想要说的下面几点

1. NameNode只记录元数据

2. NameNode不关心数据到底在哪个节点存放

3. DataNode自动汇报block信息给两个NameNode

4. 元数据的流转是Active NameNode -> Journal Nodes -> StandBy NameNode

认真理解一下上面的四点，我现在说下面这个结论你看看能不能理解

如果我要把A集群迁移到B集群，我只需要把A集群的NameNode 和journal Node（一个）的元数据拷贝到B集群，然后从A集群DataNode拷贝blcok到 B集群，这个时候B集群就可以启动起来。

什么意思呢，假设现在A集群部署了50个节点，运行了半年时间，有2TB的数据，现在搭建了一个B集群，B集群只有30个节点，现在没有数据，现在我要把A集群的数据完全迁移到B集群，并且我要保证B集群的数据和A集群一模一样，怎么做最快呢，最快的方式是哪一个U盘吧A集群的元数据拷贝到B集群，然后把A集群的 数据盘 拔了直接插到B集群的服务器上，然后重启B集群，B集群能启动起来吗，看起来比较疯狂，其实我可以很负责的说，这个肯定起的起来。

比较可惜的是，这里没有实验截图~

如果是实时同步

元数据同步：

block同步

block同步这里特别注意

这里用到了hadoop的一个特性：机架感知

所以在同步之前需要将A集群编排成3个机架，然后我们只需要同步其中一个机架上的数据过去就可以了，同步到B集群之后，B集群同样是运用机架感知的功能，会自动降数据复制成3分。

其他：块的存储