Ну я имел в виду, что я бы думал, что надо иметь возможность откатывать транзакцию.

Надо найти материалы и прочитать.

там так получается, что если такое допустить, то  participiant тогда будет вынужден уметь откатывать закомиченную транзакцию. например есть 2  participiant - "A" ,"B". Координатор спрашивает их - Prepare. Каждый из них говорит, что готов. Координатор их получает и шлет теперь всем commit. Скажем "A" закомител и сказал ack. второй же, который - "B" не смог по какой-то причине. Если вот тут допустить, что координатор может сказать и "A" откатить транзакцию (Т.к "B" не смог сделать commit), то этот  participiant "A" должен откатить уже закомиченную транзакцию. Это может быть сложным. Например кто-то уже смог залочить данные и в целом не понятно как откатывать уже закомиченые транзакции.

> что координатор может сказать и "A" откатить транзакцию

Нет, этого он сказать не может.

> то этот  participiant "A" должен откатить уже закомиченную транзакцию

Именно по этой причине, да.

Понял. Спасибо.

А к то то видел реализацию 2pc ?

Может кто-то использовал 2PC в ПРОД или там в ЮАТ? Бывают какие-то специфические с ним проблемы?

Вот ты сейчас сильно рисковал, я чуть и тебя заодно....

Я посмотрел в Википедии, вроде координатор может откатить только до начала второй фазы.

Выше

Ну так я это и написал.

Ну, они довольно редки, а в виде open source кажется их  вообще  нет.

Да, ты был прав

Почему спрашиваю про опыт использования. Там же lock держится и после фазы prepare может возникнуть ситуация, что "A" и "B" держат этот lock, а с координатором что-то случилось. Это выглядит как проблема т.к "A" и "B" не могут положиться на какой-то timeout и т.п и вынуждены держать этот лок до того момента, когда придет команда commit . А может в 2PC есть проблемы с перфомансом? Интересно бы узнать кто использовал. может там вообще что=то очень необычное часто встречается. В той же вики пишут, что иногда требуется мануальное воздействие

#DBA #MSSQLserver #TSQL #PowerShell #администраторбазданных

Компания: Usetech
📍Локация: желательно #москва или #новосибирск, также готовы рассмотреть сильных кандидатов и из других регионов
💵Зп: обсуждаем индивидуально

Какие предстоит решать задачи:
- Технологическая поддержка брокерского бизнеса;
- Администрирование, обновление и сопровождение СУБД MS SQL Server;
- Анализ производительности работы СУБД, выявление проблем и оптимизация, взаимодействие с разработчиками;
- Мониторинг, обеспечение бесперебойной работы и доступности СУБД;
- Формирование планов и схем резервного копирования, проведения регламентных работ, контроль и анализ результата;
- Разработка и ведение технической документации.

Потребуются следующие знания и навыки:
- Опыт решения проблем производительности и восстановления работоспособности БД MS SQL Server для бизнес критичных систем;
- Понимание принципов работы и особенностей СУБД MS SQL;
- Знание технологий отказоустойчивости и высокой доступности: Mirroring, Failover Clustering, Always On (группы, реплики и режимы доступности), SQL Service Broker;
- Знание и опыт написания запросов на T-SQL, скриптов на PowerShell; автоматизации с помощью скриптов 6и систем автоматизации;
- Знание MS SQL Server на уровне администратора;
- Уровень знания английского языка, необходимый для чтения специализированной литературы.

Будет дополнительным плюсом:
- Знания и опыт в настройке, поддержке высоконагруженного отказоустойчивого кластера и построения распределенных кластеров БД;
- Опыт работы в банке или финансовой организации.

Мы предлагаем:
- Интересные и сложные задачи на основе современного стека технологий;
- Гибкое утро (начало работы между 08.00 -12.00);
-Полис медицинского страхования (ДМС);
- Оплата обучения и сертификаций;
- Регулярные внутренние семинары, посвященные новым технологиям и самым актуальным темам в области разработки, аналитики и тестирования;
- Ежегодный пересмотр заработной платы в сторону увеличения.

Буду признательна за отклики и рекомендации (да-да, мы платим за рекомендации😉) @hr_AnnaShestovina

Всем привет
Подскажите плз по rt в sphinx3/manticore , в частности mva
есть index goods {
   type = rt
   rt_attr_multi = types
}

в types лежат ид записей имеющих вид типа create table types(id int, priority int)

нужно отфильтровать goods по сумме priority в столбце types

чет совсем вариантов не вижу, единственное что нагуглил https://stackoverflow.com/questions/24051419/sphinx-mva-with-rt-attr-string , но там говорят нельзя

Ребят, с толкнулся с такой ситуацией на postgresql 13
Время когда по записи отправился коммит 16:39:21.096
Время когда запрос пошел за этой записью 16:39:21.119

Получил старую запись. Это нормальное поведение? Коммит не успел произойти в бд?

Ребят, а как можно поменять значении с местами при выводе? Например: Александр Петрович  Вывод: Петрович Александр

substring'ами, charindex'ами, right'ами и left'ами

Ещё как вариант. Если много слов будет. Привести к массиву, затем реверс массива и назад в строку