ну а вообще в чем проблема? у luajit и tarantool точно такие же символы экспортированы, что и у liblua5.1

если liblua не слинкован статически используются уже загруженые в процессе символы

Ого, здорово. 👍

👍 Попробую. Спасибо

Всем привет! Настраивали мастер мастер реплику для одного проекта - все ок. На втором с идентичным конфигом при старте на каждой точке - ER_READONLY: Can't modify data because this instance is in read-only mode.

В какую сторону думать? Данные терять очень не хочется

надо больше логов и входных данных

Понял, в процессе

box.info скиньте с обоих

@ochaton Dmitry
С одной стороны:
https://paste.ee/p/kiEOs

С другой стороны:
https://paste.ee/p/BJ5FY

Сетевые дырки имеются.

Если этой информации недостаточно, то будем пробовать еще раз (это прод, сейчас запущен без реплики)

Спасибо)

Запускаются сразу две тачки ансиблом

ну видно же, что одна нода не может подрубиться к другой и уходит в orphaned и в ридонли
У вас фаером порт реплики не закрыт на 5.61.239.173?

я обратил на это внимание, пробовал уточнить:
> дырки есть, коннект не приходит так как на той стороне висит ER_READONLY

Такое может быть?

Сейчас дырки проверили ещё раз - все ок

прям telnet-ом подрубаетесь в обе стороны?

А у вас у первого уже есть кластер.

Что вы прописываете в box.cfg.replication на первом и втором? > по логу видно, что обоих

Так как уже есть мастер с кластером, его можно вывести из орфана поставив ему replication_connect_quorum = 1 (если он есть сам у себя в replication), либо 0. После этого он должен перейти в rw (можно будет проверить по box.info.ro и box.info.status).
Затем поднимаете вторую реплику, и после бутстрапа возвращаете значение кворума

Полностью идентичные конфиги, как по гайду в доке (мастер-мастер).
Спасибо за информацию, сейчас будем пробовать

Добрый день, хотел бы узнать, почему в sql тригере, в объект new не прокидывается сгенерированный id (new.id показывается как NULL). Тогда как в nosql тригере все прокидывается.
tarantool: 2.6.2-11
Прошу помочь, ибо очень хотелось бы использовать sql тригеры в tarantool

Вот сам тригер:

https://gist.github.com/AlexanderBich/cba6ffabf5945ff52ba702f02fa4cfaf

Вот sql таблиц:

STREETS:
https://gist.github.com/AlexanderBich/c35fdb4d1ac4c1460415d463e59d3430

__STREETS:
https://gist.github.com/AlexanderBich/1338e26435a7878157129aee2e42a0b4

Тригер и весь остальной sql рабочий.
Если отключить тригер, то запись создается со сгенерированным id.
Если со включеным тригером вместо NULL в значения id прокинуть число, то все отрабатывает отлично и запись создается с прокинутым id в 2 таблицах.
Если со включеным тригером прокинуть NULL  в значение id, то оно отдает ошибку: Failed to execute SQL statement: NOT NULL constraint failed: __STREETS.ID'
И в действительность внутри у new.id значение NULL вместо сгенерированного.
Повторюсь, что у аналогичного тригера написанного на nosql все срабатывает отлично, и там сгенерированное значение id в тригере присутсвует

P.S.
не обращайте внимание что кейс разный, и  где-то varchar, а где-то string, ибо это сгенерированный код.

Если это бага, то могу оформить issue в гите

тут вопрос в какой триггер в nosql прокидывается

before или after

тайминг у этих триггеров разный.