Интересно было почитать и про саму проблему, и про процесс моделирования.
В очередной раз вдохновился силой человеческого разума, способного решать такие нетривиальные задачи, как например, избегание столкновения с частицами размером ВСЕГО в 10 см.
У меня появилось несколько вопросов и предложений:
1) Подскажите, пожалуйста, какая логика применяется при падении реплики: она пытается максимально восстановить данные по своему журналу или она сразу при восстановлении копирует журнал мастера?
2) Рассмотрим репликасет из 3 инстансов, где у нас никогда не меняется мастер и транзакции всегда применяются (подтверждаются) только на 2 инстансах (мастере и ещё на одном инстансе). Я правильно понимаю, что может возникнуть ситуация, когда на оставшемся инстансе никогда не применяется транзакция (из-за какой-то аномалии) и при этом репликасет продолжает исправно функционировать?
Если мы используем follower-инстансы для распределения read-нагрузки, мы ведь всегда будем получать с этого аномального инстанса старые данные. Или даже если такой инстанс иногда применяет транзакции, он всё равно какие-то из них может пропустить, и клиент будет читать с него неполноценные таблицы.
3)
он [менеджер транзакиций для Memtx] появился в релизе 2.6 стараниями Александра Ляпунова, о чём тот расскажет в своей статье.
Мне кажется, можно прикрепить сюда ссылку на эту статью.
4) Подскажите, пожалуйста, что из себя представляет журнал Raft. Это какая-то отдельная in-memory структура? Я правильно понимаю, что vclock -- часть этой структуры?
5) Первое упоминание vclock встречается в подразделе 5, а пояснение "vclock — векторные часы; структура, ..." идёт в подразделе 6. Думаю, пояснение стоит разместить сразу после первого упоминания, чтобы читатели не ходили лишний раз в гугл.
6) В репозитории с примерами написано: "Synchronous replication and leader election are currently in beta state. You may get the latest tarantool version here". Скажите, пожалуйста, на данный момент реализация Raft'a вышла из состояния бета-версии?
Спасибо за статью! Было интересно почитать. Оставлю несколько предложений и вопросов:
1) В коде с примером работы Region в 10 строчке должно быть &fiber()->gc, AnotherItem) (пропущена скобка).
А ещё функция region_alloc_object_xc не представлена в списке сразу после заголовка "Region" (там есть только region_alloc).
2) В описании LSRegion при упоминании LSM-дерева, мне кажется, уместно прикрепить ссылку на статью (только, может быть, стоит упомянуть, что она довольно убойная).
3) В разделе про OBuf, наверное, стоит добавить: "Когда Tarantool отвечает НА запрос по сети" .
4) В разделе про Small alloc слово задублировалось: "и такой БЛОК БЛОК будет результатом".
Не очень понятно, почему Small alloc с мемпулами используется именно для кортежей? Разве под них не нужно выделить один кусок памяти размером с сам этот кортеж?
5) В разделе про Matras тоже слово задублировалось: "в любой момент МОЖНО текущее состояние всех данных в одном Matras МОЖНО моментально".
В этом ^^^ же разделе говориться про несколько потоков: "свободно использовать, например, в другом ПОТОКЕ без всяких мьютексов". Приведите, пожалуйста, пример потока, о котором идёт речь. Спрашиваю, потому что у Тарантула ведь один транзакционный поток.
Объясните, пожалуйста, когда может быть полезна ситуация "Для писателя элементы для него уже будут лежать в другом месте, а для читателя — в старом.". Разве это не означает, что у читателя будут старые данные?
Information
Rating
Does not participate
Location
Санкт-Петербург, Санкт-Петербург и область, Россия
Спасибо за статью!
Интересно было почитать и про саму проблему, и про процесс моделирования.
В очередной раз вдохновился силой человеческого разума, способного решать такие нетривиальные задачи, как например, избегание столкновения с частицами размером ВСЕГО в 10 см.
Спасибо за статью!
У меня появилось несколько вопросов и предложений:
1) Подскажите, пожалуйста, какая логика применяется при падении реплики: она пытается максимально восстановить данные по своему журналу или она сразу при восстановлении копирует журнал мастера?
2) Рассмотрим репликасет из 3 инстансов, где у нас никогда не меняется мастер и транзакции всегда применяются (подтверждаются) только на 2 инстансах (мастере и ещё на одном инстансе). Я правильно понимаю, что может возникнуть ситуация, когда на оставшемся инстансе никогда не применяется транзакция (из-за какой-то аномалии) и при этом репликасет продолжает исправно функционировать?
Если мы используем follower-инстансы для распределения read-нагрузки, мы ведь всегда будем получать с этого аномального инстанса старые данные. Или даже если такой инстанс иногда применяет транзакции, он всё равно какие-то из них может пропустить, и клиент будет читать с него неполноценные таблицы.
3)
Мне кажется, можно прикрепить сюда ссылку на эту статью.
4) Подскажите, пожалуйста, что из себя представляет журнал Raft. Это какая-то отдельная in-memory структура? Я правильно понимаю, что vclock -- часть этой структуры?
5) Первое упоминание vclock встречается в подразделе 5, а пояснение "vclock — векторные часы; структура, ..." идёт в подразделе 6. Думаю, пояснение стоит разместить сразу после первого упоминания, чтобы читатели не ходили лишний раз в гугл.
6) В репозитории с примерами написано: "Synchronous replication and leader election are currently in beta state. You may get the latest tarantool version here".
Скажите, пожалуйста, на данный момент реализация Raft'a вышла из состояния бета-версии?
Спасибо за статью! Было интересно почитать. Оставлю несколько предложений и вопросов:
1) В коде с примером работы Region в 10 строчке должно быть
&fiber()->gc, AnotherItem)(пропущена скобка).А ещё функция
region_alloc_object_xcне представлена в списке сразу после заголовка "Region" (там есть толькоregion_alloc).2) В описании LSRegion при упоминании LSM-дерева, мне кажется, уместно прикрепить ссылку на статью (только, может быть, стоит упомянуть, что она довольно убойная).
3) В разделе про OBuf, наверное, стоит добавить: "Когда Tarantool отвечает НА запрос по сети" .
4) В разделе про Small alloc слово задублировалось: "и такой БЛОК БЛОК будет результатом".
Не очень понятно, почему Small alloc с мемпулами используется именно для кортежей? Разве под них не нужно выделить один кусок памяти размером с сам этот кортеж?
5) В разделе про Matras тоже слово задублировалось: "в любой момент МОЖНО текущее состояние всех данных в одном Matras МОЖНО моментально".
Думаю, опечатка: "
ИПРИ перезаписи какого-нибудь элемента...".В этом ^^^ же разделе говориться про несколько потоков: "свободно использовать, например, в другом ПОТОКЕ без всяких мьютексов". Приведите, пожалуйста, пример потока, о котором идёт речь. Спрашиваю, потому что у Тарантула ведь один транзакционный поток.
Объясните, пожалуйста, когда может быть полезна ситуация "Для писателя элементы для него уже будут лежать в другом месте, а для читателя — в старом.". Разве это не означает, что у читателя будут старые данные?