[背景]
一个系统，现在从服务器A搬到服务器B，所有的数据有已经搬好之后，修改域名解析。
[问题]
域名生效有延迟，在这个过程中，假如有用户解析到了A服务器，并且进行了一系列的操作，这部分保留在A服务器的新数据怎么办？
一个系统，现在从服务器A搬到服务器B，所有的数据有已经搬好之后，修改域名解析。
[问题]
域名生效有延迟，在这个过程中，假如有用户解析到了A服务器，并且进行了一系列的操作，这部分保留在A服务器的新数据怎么办？
This topic created in 4650 days ago, the information mentioned may be changed or developed.
Supplement 1 · Feb 10, 2014
大家的回复都是如何去迁移，下次再遇到的时候，值得参考。
但现在的问题是，差异的数据已经产生了，怎么去把A服务器的数据合并到B服务器上面。
举个栗子
A服务器上面，被用户
新建了一条记录，对应post-id=10；
修改了一条记录，对应post-id=8；
新建了一条关联记录，把post-id=10与post-id=8关联起来。
B服务器上面，同样，被另外一些用户，
新建了一篇日志，对应post-id=10;
手动合并的话，需要下面几步
* 把A.post-id-10这条记录，以不带post-id进行insert的形式，插入到B中，获得新的post-id=11
* 把A.post-id-8这条记录，以update的形式，更新B里面的post-id-8
* 新建关联记录，把post-id-11与post-id-8关联起来
上面这个例子，数据量多、关联表多的时候，搞起来好蛋疼。
最麻烦的就是这种关联数据的ID变更，也没想到什么好的方法来写脚本简化这个迁移过程。
现在使用的方案是，在A服务器的表中，新建一个temp_id的字段，把旧的ID给保存起来。
对于B里面不存在的数据，已不带post-id的方式进行insert的方式，导入到B中，然后根据temp_id来重新生成一遍这些关联。
至于那种update的数据，就直接用update的方式。
现在这个方案，虽说解决了问题，但还是很繁琐，容易出错，所以想看看其他人的意见。
但现在的问题是，差异的数据已经产生了，怎么去把A服务器的数据合并到B服务器上面。
举个栗子
A服务器上面，被用户
新建了一条记录，对应post-id=10；
修改了一条记录，对应post-id=8；
新建了一条关联记录，把post-id=10与post-id=8关联起来。
B服务器上面，同样，被另外一些用户，
新建了一篇日志，对应post-id=10;
手动合并的话，需要下面几步
* 把A.post-id-10这条记录，以不带post-id进行insert的形式，插入到B中，获得新的post-id=11
* 把A.post-id-8这条记录，以update的形式，更新B里面的post-id-8
* 新建关联记录，把post-id-11与post-id-8关联起来
上面这个例子，数据量多、关联表多的时候，搞起来好蛋疼。
最麻烦的就是这种关联数据的ID变更，也没想到什么好的方法来写脚本简化这个迁移过程。
现在使用的方案是，在A服务器的表中，新建一个temp_id的字段，把旧的ID给保存起来。
对于B里面不存在的数据，已不带post-id的方式进行insert的方式，导入到B中，然后根据temp_id来重新生成一遍这些关联。
至于那种update的数据，就直接用update的方式。
现在这个方案，虽说解决了问题，但还是很繁琐，容易出错，所以想看看其他人的意见。
Supplement 2 · Feb 12, 2014
现在的问题是如何合并差异的数据啊亲
 |
orzflyFeb 10, 2014
1
在 A 上做反代或者端口转发到 B 上？
|
 |
2
省事做法，A提示维护中请稍后访问。
|
1 |
alexrezitFeb 10, 2014
3
搬迁过程中 A 设为 RO.
|
 |
rainciousFeb 10, 2014
4
原有服务器A，A上有数据库+Web（无论多复杂的系统其实就是界面+数据）；
新服务器B，安排在用户操作最少+用最短时间署迁移数据库部分，然后开放B上数据库的访问接口，将A上的访问数据库指向到B服务器上。（也可以做主从库访问），这样就不会导致数据不一致的问题了。 当稳定时，关闭A上的数据库，备份，迁移程序和其他部分，然后慢慢撤销指向A的解析。 完成。 |
 |
adrianzhangFeb 10, 2014
5
服务器A的IP挂到B上面去，然后改了DNS解析，过了一天A服务器IP就应该没有什么访问了吧？
|
 |
yemoluoFeb 10, 2014
6
@adrianzhang 我们直接RO
|
|
adrianzhangFeb 10, 2014
7
@GTim 恩，要没要求必须可写的话做RO就可以。
|
 |
8
RO是read only的意思？
|
 |
misakaFeb 10, 2014 via Android
9
|
 |
zeinimaFeb 11, 2014
10
数据库放在C，附件放在D
爱谁谁 |
 |
fatpaFeb 11, 2014
11
把迁移时间放在半夜，应该就没啥影响了
|
 |
dndxFeb 11, 2014
12
迁移前两天，修改记录 TTL 到一个很小的值，比如 10 秒。
挑流量最少的时候，先把原站 RO， 再修改解析到新 IP。 这样应该可以最小化影响。 |
 |
msg7086Feb 11, 2014
13
数据迁移完毕以后把A改成反代就行了，然后DNS什么时候生效都无所谓。
|
 |
julyclydeFeb 12, 2014
14
迁移完成后，立即进行原子切换，把旧的从实体运行改为proxy_pass
然后再改域名 |
|
julyclydeFeb 12, 2014
15
已经差异了就困难了。除非你的应用程序有工作日志，去另外一遍replay一遍日志就得了
|
 |
jk2rFeb 12, 2014
16
你A服务器不会是 端 + DB 吧，那就没解了。
要解决DB上行，数据不一致么？SQL/NoSQL得有IP或域名对吧，去A上设置hosts，域名指向B新机器的IP，就写过去了。。。 哈哈哈哈，仅供参考，曾经这么干过。。问题也多。A、B不是一个机房的，访问就很慢。 |
|
jk2rFeb 12, 2014
17
先切过去再慢慢修吧。The damage is done
半夜，悄悄的，操起mysql改吧。。数据不多就手动修SQL脚本，多就写个脚本搞。 可以当作新数据。 |
 |
evefree2Feb 12, 2014
18
切的1秒先锁库...
|
 |
lyragosaFeb 14, 2014
19
关掉原站，我就是这么干的
|
Select Language