-
Notifications
You must be signed in to change notification settings - Fork 10
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Replication is not correct (online/offline), master-master #64
Comments
NB: @vebmaster noted in a chat that repcached offers the behaviour he desires. The problem looks quite common for a bidirectional replication with a single writeable instance (master). I would propose the following procedure. Switching of masters requires waiting of all operations from a past master. If the waiting timed out, then the old master must not join the replicaset anymore and should be rebootstrapped (all snaps and xlogs deleted). In fact, it is the manual failover. What about automatic failover?
I'm not much in the necessary context, but it seems qsync + raft should work as the automatic failover. I guess asynchronous replication + raft will not (what kind of manual actions are required so?). Cartridge should work, but I don't know whether it is easy or hard to run the memcached module under it. I would summon replication sages: @sergos, @sergepetrenko, @Gerold103 and @Mons to correct me or propose something else. // We can discuss it in Russian in the Russian Telegram chat, but I would prefer English for discussions around the code and issues to make them available for everyone. |
@Totktonada thx. |
The memcached module has its own expiration: no need to use expirationd for records eviction. |
Hi.
tarantool 2.4.3.0.g5180d98f1-1
tarantool-memcached from git https://github.com/tarantool/memcached
В низу сообщения текст на русском.
Replication is not correct with memcached.
I have two virtual machines: s1, s2.
master-master
1)
STATE:
s1 - online
s2 - online
ACTION:
s2 -> offline
2)
STATE:
s1 - online
s2 - offline
ACTION:
s1:
s1 -> offline
s2 -> online
3)
STATE:
s1 - offline
s2 - online
ACTION:
s2:
s1 -> online
4)
STATE:
s1 - online
s2 - online
ACTION:
s1:
s2:
'q1' on 's2' FAIL?
On the 's2' server, the q1 variable should be 12345, because this is the most recent value entered and all replicas and masters should be 12345.
master.lua on s1:
master.lua on s2:
НА РУССКОМ:
Здравствуйте.
Заметил, что не правильно реплицируются данные, добавленные в memcached при работе тарантула как master-master.
По логике самым приоритетным значением, которое должно иметь вес должно быть то, которое добавлено самое последнее по времени.
Пример:
имеем два сервера s1 и s2.
Оба сервера ОНЛАЙН.
Отключаем интернет на s2.
На s1 добавляем две переменные:
q1 = 11
q2 = 22
Отключаем интернет на s1.
Включаем интернет на s2.
На s2 добавляем переменную q1 = 12345
Включаем интернет на s1.
Сервера реплицируются.
Считываем переменные с обоих серверов
На s1:
q1 = 12345 (правильно)
q2 = 22
На s2:
q1 = 11 (НЕ правильно)
q2 = 22
Т.к. последним была добавлена переменная q1=12345 на s2, то это значение и должно реплицироваться на все сервера.
s1 сервер считал q1 значение с s2, но s2 счёл за приоритет значение из s1 сервера, а оно уже УСТАРЕВШЕЕ! Что не правильно по логике.
Я прав и логика репликации не верная или всё таки я не правильно рассуждаю?
Если можно, то лучше вести переписку на русском. Спасибо.
The text was updated successfully, but these errors were encountered: