服务器迁移的两种方式浅谈
最近在处理服务器机房迁移的事宜，很多事情其实看起来简单，但是实现的时候总会有一些不如意的地方，很可能你考虑的是一个看起来非常稳定完美的迁移，但是实现中总会有这样那样的限制最后不得不采用一种混合式或者看起来有些别扭的方式来实现。这种方式里面有一个坑就是如果一旦看到这种迂回或者别扭的方式能够改善问题，那么后续再想进一步改进问题，就会有潜意识中的懒惰和不情愿，而这个也是我们碰到的很多遗留问题，兼容问题的源头，有时候我们说我们说这个东西太烂，那个一点都不高级，其实很多时候我们就是始作俑者。
我们来看看目前的服务器架构模式，目前的主要业务会采用一主两备的架构模式，一主一备在同机房，便于服务切换，IP可以无缝对调，另外一个备库在异地机房，作为前两道防线崩溃之后的补充。实现方式如下图所示：
当然有一天我们突然接到了一个需求，是某一个机房要撤销，即下图中的机房1要撤销了，目前有机房2，机房3可供选择。
针对这种情况，需要讨论的是怎么来实施而不是迁移的目的，能不能迁移。
一种方案就是把机房1里的备库先搬迁到机房3，然后在机房3里面添加一个新的备库服务器，然后在迁移的时候主从切换，切换后链接备库1和备库2即可。
切换完成之后，机房1的主库服务器就可以集中下架，作为后续的补充资源所
这种方式的优点是步骤比较简单可行，很多准备工作在前期都会完成即可。可以简单归纳为半搬迁，半迁移。
第二种迁移方式看起来略微臃肿，但是也是很多情况下的无奈之选。
我们还是看看最开始的场景，一主两备。
然后我们在机房3准备了一主一备的环境，到时候迁移时还是主从切换，机房1的主备服务器就保持原样，统一下架。
这种方式对于服务器的数量是一个很大的要求，但是这种迁移方式可行性略高，因为碰到机房管理不规范，布线不够规范的情况下，这种方式的余地最大，先迁移再搬迁。
如果这两种思想混合起来就是一种很折中的方式，说实话，我对这种情况不满意，但是又无奈。
我们来看看目前的服务器架构模式，目前的主要业务会采用一主两备的架构模式，一主一备在同机房，便于服务切换，IP可以无缝对调，另外一个备库在异地机房，作为前两道防线崩溃之后的补充。实现方式如下图所示：
当然有一天我们突然接到了一个需求，是某一个机房要撤销，即下图中的机房1要撤销了，目前有机房2，机房3可供选择。
针对这种情况，需要讨论的是怎么来实施而不是迁移的目的，能不能迁移。
一种方案就是把机房1里的备库先搬迁到机房3，然后在机房3里面添加一个新的备库服务器，然后在迁移的时候主从切换，切换后链接备库1和备库2即可。
切换完成之后，机房1的主库服务器就可以集中下架，作为后续的补充资源所
这种方式的优点是步骤比较简单可行，很多准备工作在前期都会完成即可。可以简单归纳为半搬迁，半迁移。
第二种迁移方式看起来略微臃肿，但是也是很多情况下的无奈之选。
我们还是看看最开始的场景，一主两备。
然后我们在机房3准备了一主一备的环境，到时候迁移时还是主从切换，机房1的主备服务器就保持原样，统一下架。
这种方式对于服务器的数量是一个很大的要求，但是这种迁移方式可行性略高，因为碰到机房管理不规范，布线不够规范的情况下，这种方式的余地最大，先迁移再搬迁。
如果这两种思想混合起来就是一种很折中的方式，说实话，我对这种情况不满意，但是又无奈。
正文到此结束
热门推荐
相关文章
近期评论
-
文章和留言都翻到11页了 没有OOM
-
-
朋友，翻页到11页，及以后，会出现OOM，无法访问
-
-
搞个gitee的项目
-
-
版本号是多少，你可以下载哪个代码仓库，jdk选1.8 直接跑就行
-
-
-
Loading...
![[HBLOG]公众号](https://www.liuhaihua.cn/img/qrcode_gzh.jpg)
