S***w
发帖数: 1014 | 1 这个有点想不明白
当我们写Master的时候，Master负责先写自己，等成功后，再写Slave，两者都成功后
返回成功，整个过程是同步的，如果写Slave失败了，master回滚自己并返回写失败
如果分布式的， slave写成功，但是传给master的确认消息在传输的时候丢了
然后master会滚回原来状态
这时候
master: old data
slave: new data
数据不一致了，怎么处理这种情况呢
多谢 |
l*********s
发帖数: 5409 | 2 master has more than slaves and uses majority-voting to decide whether to
roll back. |
g*****g
发帖数: 34805 | 3 分布式的做法通常是 master写成功就返回，然后再慢慢异步写 slave. 所以没有你说
的问题。
【在 S***w 的大作中提到】
: 这个有点想不明白
: 当我们写Master的时候，Master负责先写自己，等成功后，再写Slave，两者都成功后
: 返回成功，整个过程是同步的，如果写Slave失败了，master回滚自己并返回写失败
: 如果分布式的， slave写成功，但是传给master的确认消息在传输的时候丢了
: 然后master会滚回原来状态
: 这时候
: master: old data
: slave: new data
: 数据不一致了，怎么处理这种情况呢
: 多谢
|
d****n
发帖数: 1637 | 4 return ack ->writeFalure or not return anything (timeout) are different
Errors
server shall catch and handle them separately.
e.g
if time_out:
try 3,2,1
still failure -> you make the call
either wait forever or wait until slave response, then sync-up with
master
if ack-ed && ack == failure
rollback
【在 S***w 的大作中提到】
: 这个有点想不明白
: 当我们写Master的时候，Master负责先写自己，等成功后，再写Slave，两者都成功后
: 返回成功，整个过程是同步的，如果写Slave失败了，master回滚自己并返回写失败
: 如果分布式的， slave写成功，但是传给master的确认消息在传输的时候丢了
: 然后master会滚回原来状态
: 这时候
: master: old data
: slave: new data
: 数据不一致了，怎么处理这种情况呢
: 多谢
|
S***w
发帖数: 1014 | 5 瞎忙了一天，这么多回复，谢谢大家
@littlebirds
master has more than slaves and uses majority-voting to decide whether to
roll back.
你说的这是 两段提交吧
有个问题一没明白， 如果发送消息丢了
假设决定commit, 但是消息丢了， slave怎么办？ |
S***w
发帖数: 1014 | 6 这是 eventual consistence吧
如果想strong consistence呢
【在 g*****g 的大作中提到】
: 分布式的做法通常是 master写成功就返回，然后再慢慢异步写 slave. 所以没有你说
: 的问题。
|
g*****g
发帖数: 34805 | 7 Master Slave 都是这种架构，未传给 slave的在 commit log里，所以就算Master
crash 也不见得会丢。读 master就 strong consistency.
要 p2p架构的可以看 Cassandra.
【在 S***w 的大作中提到】
: 这是 eventual consistence吧
: 如果想strong consistence呢
|
b********h
发帖数: 119 | 8 If waiting for commit-ack timed out, and master rolls back, the relationship
between master and slave needs to be re-established. That means, slave
needs to re-sync with master, the committed tx will be rolled back at that
time.
【在 S***w 的大作中提到】
: 这个有点想不明白
: 当我们写Master的时候，Master负责先写自己，等成功后，再写Slave，两者都成功后
: 返回成功，整个过程是同步的，如果写Slave失败了，master回滚自己并返回写失败
: 如果分布式的， slave写成功，但是传给master的确认消息在传输的时候丢了
: 然后master会滚回原来状态
: 这时候
: master: old data
: slave: new data
: 数据不一致了，怎么处理这种情况呢
: 多谢
|
w**z
发帖数: 8232 | 9 strong consistency is very hard to achieve in distributed system. read below
for MySQL replication problem.
http://gtowey.blogspot.com/2012/10/how-can-mysql-replication-br
【在 S***w 的大作中提到】
: 这是 eventual consistence吧
: 如果想strong consistence呢
|
r***r
发帖数: 39 | 10 这是异步复制。也有同步复制的。
【在 g*****g 的大作中提到】
: Master Slave 都是这种架构，未传给 slave的在 commit log里，所以就算Master
: crash 也不见得会丢。读 master就 strong consistency.
: 要 p2p架构的可以看 Cassandra.
|
S***w
发帖数: 1014 | 11 多谢
relationship
【在 b********h 的大作中提到】
: If waiting for commit-ack timed out, and master rolls back, the relationship
: between master and slave needs to be re-established. That means, slave
: needs to re-sync with master, the committed tx will be rolled back at that
: time.
|
S***w
发帖数: 1014 | 12 多谢大牛回复
我再仔细看看
below
【在 w**z 的大作中提到】
: strong consistency is very hard to achieve in distributed system. read below
: for MySQL replication problem.
: http://gtowey.blogspot.com/2012/10/how-can-mysql-replication-br
|
