AL
по теме: Consistent Map-Reduce in vshard
https://github.com/tarantool/vshard/discussions/261
@olegrok @gerold103
Нужно предусмотреть возможность включения pin не только при вызове со стороны роутера, но и непосредственно с самого репликасета.
Сценарий может быть такой :
Файберы на репликасетах получают задания из системы событий (внутренней или внешней это неважно) и понимают что на время обработки события нужно залочить все перемещения бакетов, например это может быть полезно для миграций , когда нужно все существующие и вновь приходящие данные обработать; при этом может понадобиться согласование с остальными репликасетами, но опять же это можно сделать и через внешний стейт менеджер, лишь бы была возможность взять pin и не отпускать его ни в коем случае пока явно не будет сигнала... Это может показаться похожим на двухфазное отключение шедулера и затем двухфазное включение, но это не совсем так... скорее это двухфазное снятие пинов
Другой пример использования:
(такое могло бы быть применимо в crud )
ситуации когда tuple-merger невозможно использовать из за мультикей индексов или когда вообще нужен курсор и сортировка не по текущим индексам, в таком случае должна использоваться техника временных таблиц, при которой каждый воркер map скрринит данные в своем репликасете в тот момент когда ему удалось взять pin и затем отправляет во временное хранилище для reduce и сортировки, после чего уже роутер может свободно по курсору отдавать данные; тоесть это такой асинхронный подход когда момент принятия заявки на map reduce может не совпадать с моментом его фактического исполнения.
что касается решения map reduce в лоб то не совсем ясно как использовать курсор в случае работы с mcallrw , ведь все время пока не вышел таймаут и курсор не закрыт нужно держать пины на шардах , скажем как клиенту имея уже открытый курсор делать последовательные запросы к роутеру для получения следующей порции данных...
выходит что нужно держать пины открытыми пока все выполнится.
в примере который я описал выше таких проблем нет вообще, там и обход проблемы мерджера с мультикей и курсор в любое место и лишних блокировок нет пока клиент забирает данные , минус только временная таблица.
===
Кроме того, было бы не плохо сделать систему триггеров или хуков, для случая когда шедулер запланировал перемещения чтобы он мог посигналиить и "мягко" попросить по возможности завершиться фоновым таскам и снять пины.
хотелки:
Такая же система хуков или триггеров нужна и при смене rw - ro , нужно иметь возможность "попросить " снять ref rw, но об этом я много писал в тикетах vshard...
То же самое и о процессе выключения , тоесть при переходе из ro в ничто , нужно иметь возможность дождаться снятия pin и ref предварительно "предупредив " о скором завершении.
На текущий момент по факту все переключения rw- ro и выключения - это жесткое отрубалово вместо реджекта вновь прибывших и ожидания завершения текущих.
