Такой настройки нет. Данные от "выпавшего" мастера не вернуть обратно в реплику, если реплика уже переизбрала другого мастера и ушла вперед.
Но если правильно установить параметры запросов и не игнорировать сообщения об ошибках, которые приходят из базы данных, то возвращать такие данные в реплику и не потребуется.
Да, все верно. Ошибка - это сигнал о неопределенном состоянии данных в системе. И прежде чем продолжать работу, нужно выяснить реальное состояние и возможно дождаться достижения согласованного состояния в узлах системы.
Как я отмечал в статье, при работе с любой базой данных, в том числе и Postgresql, могут произойти разные ситуации приводящие к одной и тоже ошибке. Например:
запрос клиента может дойти до сервера БД выполниться, но ответ об успешном выполнении операции может не дойти до клиента и клиент получит ошибку timeout,
запрос клиента может не дойти до сервера БД, соответственно не выполниться, и клиент получит точно такую же ошибку timeout.
Отличный вопрос, "главный адвокат"! Компенсирующие действия клиента будут зависеть от типа запроса. Полученную от сервера ошибку нужно интерпретировать как неопределенное состояние базы данных. Поэтому, если запрос к базе данных идемпотентный, то, конечно, его можно повторить. Если же запрос опирается на данные в базе, то перед выполнением ретрая необходимо выяснить реальное состояние данных: возможно, они уже изменились на сервере, и тогда следует отказаться от ретрая, чтобы на счету не оказалось +200 попугаев. Однако есть «подводный камень», который неочевиден: ошибка может означать, что данные были применены на primary-узле, но потенциально могут исчезнуть при неблагоприятных условиях (см. раздел «Потеря данных в наборе реплик»). Поэтому перед ретраем неидемпотентного запроса потребуется проверить согласованность данных в наборе реплик, то есть прочитать данные дважды: сначала с primary-узла (параметры {readConcern: "local", readPreference: "primary"}), а затем — данные, подтверждённые большинством узлов (параметр {readConcern: "majority"}). Если данные различаются, то сначала нужно дождаться репликации и достижения согласованного состояния всего набора реплик. Если же данные совпали, состояние набора реплик считается согласованным, и на основе этих данных можно принимать решение о повторной отправке запроса.
Да, в абсолютном значении конечно будут отличаться. При сетевом взаимодействии узлов будет влиять очень много факторов, но относительно друг друга цифры будут релевантны. Более того, из-за низкой скорости работы стенда на одном ноутбуке, достаточно просто удается поймать интересные моменты состояний репликации данных, которые в сетевом режиме не удалось бы увидеть, если только не разворачивать специальный софт по замедлению работы.
Метод Zettelkasten — супер, но удобство поддерживающих его приложений оставляет желать лучшего (если есть одна важная в работе функция, то нет другой), а Notion для данной задачи вообще далек от идеала.
Очень подходит новая платформа Torrow.Net с приложениями под iOS/Android/Web, в которой реализовано ассоциативное хранение информации (MindMap заметок, контактов и событий) + теги + поиск по словам и тегам. Это позволяет создать много разных поисковых каталогов с полностью независимой или частично пересекаемой структурой, которой можно делиться с другими пользователями и совместно редактировать!
Да, прям как у Microsoft :)
Иногда нужна не богатая функциональность или множество приложений, а простая возможность работать с разными структурами данных.
Ага, все приходится хранить локально. Именно поэтому в Torrow.Net сделана возможность работать с информацией в offline, чтобы не зависеть от интернет или отсутствия доступа к серверу.
Большое спасибо за комментарий!
Приложение в первую очередь разрабатывается для мобильных телефонов (Android, iOS), полноценного клиента под «Винду» пока нет, только Web версия. Именно под «Электрон» сделаем в первую очередь, чтобы под Виндой заработал полноценный offline режим, как для мобильных телефоном.
Данные хранятся в нескольких облаках, на данный момент в Azure и Yandex.
Имеет смысл все-таки разделять приложения для создания структурно сложных оформительских заметок (с таблицами, рисунками и т.д.) и для создания кратких и быстрых заметок на ходу, где нужно зафиксировать идею и построить смысловые связи с другой информацией. Для второго типа заметок очень хорошо заходит приложение torrow.net (жаль, что автор его пропустил). Оно пока еще бесплатно и заменяет сразу блокнот, календарь и телефонную книгу, чтобы супер удобно при работе с разной информацией. Мне нравится возможность делиться и совместно редактировать целые структуры информации. Теперь с женой ведем всю семейную информацию только там, а с коллегами храним общую информацию по проектам.
Спасибо автору за статью! Я тоже не смог осилить Notion и встроить его использование в повседневную жизнь. Сделал несколько попыток настроить и удалил его. Действительно хочется установить приложение и сразу начать использовать в жизни без лишних заморочек.
В итоге, работаю в стартапе где с командой уже пару лет ведем разработку приложения, которое одновременно является календарем, блокнотом и телефонной книжкой, работает в офлайн/онлайн и реализует подходы mind map и zettelkasten.
Кому интересно можно почитать тут и установить приложение: http://info.torrow.net
Прошу строго не судить, приложение только создано и план доработок записан на полгода вперед. Мы будем благодарны, если подскажете какие функции вам требуются в первую очередь для его продуктировного использования.
Information
Rating
Does not participate
Location
Санкт-Петербург, Санкт-Петербург и область, Россия
Такой настройки нет. Данные от "выпавшего" мастера не вернуть обратно в реплику, если реплика уже переизбрала другого мастера и ушла вперед.
Но если правильно установить параметры запросов и не игнорировать сообщения об ошибках, которые приходят из базы данных, то возвращать такие данные в реплику и не потребуется.
Да, все верно. Ошибка - это сигнал о неопределенном состоянии данных в системе. И прежде чем продолжать работу, нужно выяснить реальное состояние и возможно дождаться достижения согласованного состояния в узлах системы.
Как я отмечал в статье, при работе с любой базой данных, в том числе и Postgresql, могут произойти разные ситуации приводящие к одной и тоже ошибке. Например:
запрос клиента может дойти до сервера БД выполниться, но ответ об успешном выполнении операции может не дойти до клиента и клиент получит ошибку timeout,
запрос клиента может не дойти до сервера БД, соответственно не выполниться, и клиент получит точно такую же ошибку timeout.
Отличный вопрос, "главный адвокат"!
Компенсирующие действия клиента будут зависеть от типа запроса. Полученную от сервера ошибку нужно интерпретировать как неопределенное состояние базы данных. Поэтому, если запрос к базе данных идемпотентный, то, конечно, его можно повторить. Если же запрос опирается на данные в базе, то перед выполнением ретрая необходимо выяснить реальное состояние данных: возможно, они уже изменились на сервере, и тогда следует отказаться от ретрая, чтобы на счету не оказалось +200 попугаев.
Однако есть «подводный камень», который неочевиден: ошибка может означать, что данные были применены на primary-узле, но потенциально могут исчезнуть при неблагоприятных условиях (см. раздел «Потеря данных в наборе реплик»). Поэтому перед ретраем неидемпотентного запроса потребуется проверить согласованность данных в наборе реплик, то есть прочитать данные дважды: сначала с primary-узла (параметры {readConcern: "local", readPreference: "primary"}), а затем — данные, подтверждённые большинством узлов (параметр {readConcern: "majority"}).
Если данные различаются, то сначала нужно дождаться репликации и достижения согласованного состояния всего набора реплик. Если же данные совпали, состояние набора реплик считается согласованным, и на основе этих данных можно принимать решение о повторной отправке запроса.
Да, в абсолютном значении конечно будут отличаться. При сетевом взаимодействии узлов будет влиять очень много факторов, но относительно друг друга цифры будут релевантны. Более того, из-за низкой скорости работы стенда на одном ноутбуке, достаточно просто удается поймать интересные моменты состояний репликации данных, которые в сетевом режиме не удалось бы увидеть, если только не разворачивать специальный софт по замедлению работы.
Очень подходит новая платформа Torrow.Net с приложениями под iOS/Android/Web, в которой реализовано ассоциативное хранение информации (MindMap заметок, контактов и событий) + теги + поиск по словам и тегам. Это позволяет создать много разных поисковых каталогов с полностью независимой или частично пересекаемой структурой, которой можно делиться с другими пользователями и совместно редактировать!
Иногда нужна не богатая функциональность или множество приложений, а простая возможность работать с разными структурами данных.
Приложение в первую очередь разрабатывается для мобильных телефонов (Android, iOS), полноценного клиента под «Винду» пока нет, только Web версия. Именно под «Электрон» сделаем в первую очередь, чтобы под Виндой заработал полноценный offline режим, как для мобильных телефоном.
Данные хранятся в нескольких облаках, на данный момент в Azure и Yandex.
Спасибо автору за статью! Я тоже не смог осилить Notion и встроить его использование в повседневную жизнь. Сделал несколько попыток настроить и удалил его. Действительно хочется установить приложение и сразу начать использовать в жизни без лишних заморочек.
В итоге, работаю в стартапе где с командой уже пару лет ведем разработку приложения, которое одновременно является календарем, блокнотом и телефонной книжкой, работает в офлайн/онлайн и реализует подходы mind map и zettelkasten.
Кому интересно можно почитать тут и установить приложение: http://info.torrow.net
Прошу строго не судить, приложение только создано и план доработок записан на полгода вперед. Мы будем благодарны, если подскажете какие функции вам требуются в первую очередь для его продуктировного использования.