Как MongoDB обнаруживает большинство в архитектуре PSA?

Question

Предположим, у меня есть набор реплик с 3 узлами (2 узла данных и один арбитр (PSA)). Когда по какой-то причине один из моих узлов данных выходит из строя, и я возвращаю его во время синхронизации с основным узлом, который находится в состоянии STARTUP2. В свое время я потеряю change stream, потому что в моем наборе реплик есть 2 узла данных, но у меня нет большинства узлов для чтения.

Как я могу решить эту проблему?

Я также читаю это MongoDB do c. Можно ли установить значение первичного узла priority выше, чем у вторичного узла (который синхронизируется с первичным узлом)? Могу ли я получить большинство, выполняя это, даже если мой вторичный узел находится в состоянии STARTUP2?

Answer 1

Технически существует два типа большинства. Как я их назвал, они являются «большинством на выборах» и «большинством данных».

Арбитры должны помогать с «большинством на выборах», где это помогает поддерживать первичную доступность в архитектуре PSA, если S пошел вниз. Тем не менее, они не являются частью "большинства данных".

"Большинство данных", напротив, предназначены как для голосования, так и для подтверждения чтения большинства и записи большинства .

По замыслу Changestreams будут возвращаться документы, которые переданы "большинству данных" узлов голосования. Это связано с тем, что запись, переданная им, не будет отменена . Будет непонятно, если поток изменений объявит, что документ был написан, затем он откатился, а затем пришлось бы выдавать «не ждать, поцарапать, запись не произошла».

Таким образом, по своей природе Арбитры не совместимы со сценариями чтения большинства и записи большинства ios, такими как потоки изменений или транзакции. Однако арбитры по-прежнему имеют свое место в наборе реплик, при условии, что вы знаете, чего от них ожидать.

См. Какое правило записи в mongod по умолчанию в какой версии? для более полного объяснения проблем с записью и эффекта наличия арбитров.

Вторичное в STARTUP2 еще не является вторичным. Он может голосовать на выборах, но не признает большинство записей, поскольку он все еще запускается.

С точки зрения изменений, поскольку в архитектуре PSA «большинство данных» практически является только частью PS PSA, ни один из узлов, несущих данные, не может находиться в автономном режиме для большинства операций чтения и записи, которые необходимо поддерживать.

Наилучшим решением является замена арбитра фактическим узлом, несущим данные. Таким образом, вы можете записывать большинство, читать большинство и иметь один неработающий узел и при этом поддерживать большинство.