这是一个创建于 4265 天前的主题，其中的信息可能已经有所发展或是发生改变。
[背景]
一个系统，现在从服务器A搬到服务器B，所有的数据有已经搬好之后，修改域名解析。
[问题]
域名生效有延迟，在这个过程中，假如有用户解析到了A服务器，并且进行了一系列的操作，这部分保留在A服务器的新数据怎么办？
一个系统，现在从服务器A搬到服务器B，所有的数据有已经搬好之后，修改域名解析。
[问题]
域名生效有延迟，在这个过程中，假如有用户解析到了A服务器，并且进行了一系列的操作，这部分保留在A服务器的新数据怎么办？
第 1 条附言 2014-02-10 23:02:50 +08:00
大家的回复都是如何去迁移，下次再遇到的时候，值得参考。
但现在的问题是，差异的数据已经产生了，怎么去把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的方式。
现在这个方案，虽说解决了问题，但还是很繁琐，容易出错，所以想看看其他人的意见。
第 2 条附言 2014-02-12 09:57:30 +08:00
现在的问题是如何合并差异的数据啊亲
 | 1 orzfly 2014-02-10 20:19:44 +08:00 在 A 上做反代或者端口转发到 B 上？ |
 | 2 X-Force 2014-02-10 20:31:04 +08:00  1 省事做法，A提示维护中请稍后访问。 |
 | 3 alexrezit 2014-02-10 20:35:56 +08:00 搬迁过程中 A 设为 RO. |
 | 4 raincious 2014-02-10 20:38:18 +08:00 原有服务器A，A上有数据库+Web（无论多复杂的系统其实就是界面+数据）； 新服务器B，安排在用户操作最少+用最短时间署迁移数据库部分，然后开放B上数据库的访问接口，将A上的访问数据库指向到B服务器上。（也可以做主从库访问），这样就不会导致数据不一致的问题了。 当稳定时，关闭A上的数据库，备份，迁移程序和其他部分，然后慢慢撤销指向A的解析。 完成。 |
 | 5 adrianzhang 2014-02-10 20:56:49 +08:00 服务器A的IP挂到B上面去，然后改了DNS解析，过了一天A服务器IP就应该没有什么访问了吧？ |
 | 6 yemoluo 2014-02-10 21:15:09 +08:00 @adrianzhang 我们直接RO |
| 7 adrianzhang 2014-02-10 21:39:18 +08:00 @GTim 恩，要没要求必须可写的话做RO就可以。 |
 | 8 qq286735628 OP RO是read only的意思？ |
 | 9 misaka 2014-02-10 23:58:15 +08:00 via Android |
 | 10 zeinima 2014-02-11 00:45:40 +08:00 数据库放在C，附件放在D 爱谁谁 |
 | 11 fatpa 2014-02-11 00:55:01 +08:00 把迁移时间放在半夜，应该就没啥影响了 |
 | 12 dndx 2014-02-11 02:49:14 +08:00 迁移前两天，修改记录 TTL 到一个很小的值，比如 10 秒。 挑流量最少的时候，先把原站 RO， 再修改解析到新 IP。 这样应该可以最小化影响。 |
 | 13 msg7086 2014-02-11 10:27:37 +08:00 数据迁移完毕以后把A改成反代就行了，然后DNS什么时候生效都无所谓。 |
 | 14 julyclyde 2014-02-12 10:28:59 +08:00 迁移完成后，立即进行原子切换，把旧的从实体运行改为proxy_pass 然后再改域名 |
| 15 julyclyde 2014-02-12 10:29:44 +08:00 已经差异了就困难了。除非你的应用程序有工作日志，去另外一遍replay一遍日志就得了 |
 | 16 jk2r 2014-02-12 11:29:08 +08:00 你A服务器不会是 端 + DB 吧，那就没解了。 要解决DB上行，数据不一致么？SQL/NoSQL得有IP或域名对吧，去A上设置hosts，域名指向B新机器的IP，就写过去了。。。 哈哈哈哈，仅供参考，曾经这么干过。。问题也多。A、B不是一个机房的，访问就很慢。 |
| 17 jk2r 2014-02-12 11:32:07 +08:00 先切过去再慢慢修吧。The damage is done 半夜，悄悄的，操起mysql改吧。。数据不多就手动修SQL脚本，多就写个脚本搞。 可以当作新数据。 |
 | 18 evefree2 2014-02-12 11:50:05 +08:00 切的1秒先锁库... |
 | 19 lyragosa 2014-02-14 10:13:31 +08:00 关掉原站，我就是这么干的 |
Select Language