я пытаюсь реализовать мускульный 'on duplicate key update' (https://github.com/tarantool/tarantool/issues/5732#issuecomment-860118589). Помимо примари кея, который автоинкремент, спейс может иметь более одного уникального вторичного индекса. Перебирать их, чтобы выяснить будет ли конфликт как-то не очень, поэтому моя идея инсертить и ловить ошибку с кодом 3 (дубликат) и делать апдейт. но для этого нужно знать примари ключ "старого" тапла

мб before_replace триггер поможет?

Это не решит проблему уникальных вторичек скорее всего. old_tuple в before_replace - это то, у чего совпадает праймак с new

единственный выход пока это наверное парсить строку с ошибкой

Привет
Подскажите пожалуйста, можно ли делать селект всего спейса тарантула, который находится под нагрузкой?
Что-то вроде такого: box.space.users.index.email:select()

Спейс большой, записей много. Не уйдет ли тарантул в полку по цпу, например?

Тарантул 1.10.4

НЕЛЬЗЯ

Нельзя. Не делайте select на проде

Воспользуйтесь :pairs() c вызовом fiber.yield() через n итераций и обработкой батчами
Если спейс большой, он у вас в Луа память даже не влезет

Хорошо, спасиббо

Всем добрый день, есть кластер тарантура в кубере по данному примеру - https://github.com/tarantool/examples/tree/931e4ce914ce096f855de58708af77b52e032dc9/cookbook/election, с выбором лидера и синхронной репликацией.

В этом же примере есть router.lua, который только может предоставить данные о том кто лидер.

Хотел узнать есть ли кейсы с созданием автофейловера в кубере, с подменой ендпоинтов для мастера и read-only слейвов при смене лидера?

Всем привет!
Тестирую простой сервис тарантула - 2 спейса, по http в них заливаются данные.
Кидаю через jmeter примерно 200 тыс запросов: 2 на запись и 1 на чтение.
Через 2-5 минут стабильно появляются "провалы" по времени ответа до 9 сек.

Напрягает, что значение item_used_ratio всегда стремится к 100%, а где то в доке читал что это признак нехватки памяти.
Хотя памяти выделял достаточно

Подскажите пожалуйста, в чем может быть беда, почему тарантул медленно отвечает на часть запросов и почему item_used_ratio всегда большой?

про память все хорошо, у вас квоты то пятая часть только использована

а в логах при провалах что-то интересное есть?

может вы ему ядер зажилили, а он снапшотится в это время (но это из головы версия)

В логах нет интересного (

я правильно понял, что на items_used_ratio можно не обращать внимания, главное сколько использовано памяти в  quota_used_ratio?

про снапшоттинг тоже нету? график по цпу что говорит?

Это параметр может говорить о степени фрагментированности памяти
Здесь есть хорошое описание
https://www.tarantool.io/ru/doc/latest/reference/reference_lua/box_slab/slab_info/

Но когда quota_used_ratio низкий, памяти достаточно