Я бы рекомендовал в комьюнити задать вопрос как правильно сделать https://t.me/rabbitmq_ru, но порты в мир это не вариант, у вас же порты баз данных не торчат наружу (надеюсь).
Вот неплохой материал есть https://hevodata.com/learn/rabbitmq-vs-activemq/#Understanding-the-Key-Differences. По сути там как говорится про кластеризацию, то о чём мы и писали, что RabbitMQ хорош для сложных сценариев обмена. Если доберутся руки писать о кейсах, когда лучше применим RabbitMQ, постараемся не забыть про разницу методов обмена сообщениями. P2P. PUB-SUB в ActiveMQ вполне может делать этот инструмент более полезным в каких-то частных кейсах.
Спасибо за ценный комментарий, мы забрали поднятые проблемы в список потенциальных тем по CI/CD. Для DevOps-инженеров, которые уже настраивают CI/CD в ней действительно нет нового. В этом материале план и был пройтись по основам.
Казалось бы материалов и так есть немало, но идеальных материалов не бывает. Одна статья глубже, другая понятней, в третьей описаны нюансы.
По собесам точно могу посоветовать посмотреть запись уже нашего недавнего вебинара, там в целом о работе SRE в разных компаниях и в том числе о собесах говорили немного: https://youtu.be/Cj9yKoF6hd0.
Спасибо за интересный вопрос, спрошу у спикеров курса, а так сходу могу сказать, что есть Response от Monzo, инженеры из Dodo рассказывали, что допиливали этот опенсорс, а в Wargaming`е переписывали Jira.
Спасибо за вопрос, бесплатную практику для прохождения курса мы организуем с Mail.ru Cloud Solutions и спикеры будут показывать на примере MCS. При этом делать / не делать практику, попробовать работать в другом облаке на усмотрение участника можно, чисто технически реально часть практик сделать, это от вас зависит, но спикеры рекомендуют на MCS.
Можете подробнее про процесс рассказать или ткнуть в документацию, где это описано? Какими инструментами это выполняется?
Или это просто берем по N записей и копируем в другую таблицу, пока записи не кончатся (insert into ... select from ...)? «
Если у вас есть таблица с инкрементальным номером, то проблем вытащить данные не будет. Да выполняем команду insert into … select from where id between A and B Но у нас id был uuid. Поэтому мы потратили больше времени на вытаскивания данных – из-за этого было и время остановки сервера больше. Сначала я пробовал сделать так insert into … select from where ctid in ();
Вытащил так примерно 70 процентов записей. Но потом пришлось пойти по-другому. Я нашел связанную таблицу по внешнему ключу (тут главное условие, что все данные из целевой таблицы точно должны быть в связанной таблице). И начал перебирать uuid из второй таблицы и подставлять в условие where. Так я вытащит все остальные записи.
По блокам.
Да вначале формировал блоки из 10 тыс. значений в запросе where id in (). Находит запросы, которые повисли. Вызывал повторно эти запросы, но блок уменьшал до 100 записей. Потом выискивал опять эти блоки и перебирал по 1 записи. Так и вышел на 17 битых записей.
Если нет ключа в items, то на что history ссылалась? Какая схема данных была?
Внешнего ключа не было. Так как и items и history были секционированы. Так как секционирование было сделано через наследование, то внешние ключи нельзя создать на родительской таблице. А когда делали секционирование таблицы items, то забыли сделать первичный ключ. Поэтому через какое-то время появилась описанная ситуация.
Да вы правы, можно было выставить данный параметр. В данном кластере этот параметр имел значение по умолчанию, те отсутствия таймаута. После данного инцидента он был выставлен в 1 час.
Но я в своей практики видел, когда данным параметром стреляли себе в ногу. Из-за того, что приложение написано не оптимально (что и выше кстати тоже), при выполнении длительного бизнес процесса (длительность доходила до суток) оно работало в одной транзакции. Спасало и БД и приложение, то что пользователей было немного и бизнес процессы работали с разными данными. Но как только мы выставили данный параметр в 1 час, у нас перестало работать приложение. Но так как приложение было большой монолит и переписать его не имело возможности. Поэтому после несколько часов не_работы приложения, данный параметр вернули в значение по умолчанию.
Спасибо за коммент. Мы однозначно хотим доносить до аудитории Хабра о курсах, не скрываю такого умысла. И наш контент иногда связан с курсами.
А этот перевод так точно связан, это можно сказать, отчасти запрос тех, кто проходил первый интенсив по Terraform. Материалов на русском по Terragrunt довольно немного, поэтому мы искали что-нибудь полезное и практическое для перевода.
В мировом финтехе вариаций реально много, так что такой кейс даже не редкий.
В плане рекомендаций - они применимы, ничего, что тесты на 9.5.7.
Ну вот смотрите, методы то универсальны. К примеру PAGE_SIZE 16 КБ на ARM64.
Круть, спасибо за дополнение!
Спасибо, действительно опечатка
Я бы рекомендовал в комьюнити задать вопрос как правильно сделать https://t.me/rabbitmq_ru, но порты в мир это не вариант, у вас же порты баз данных не торчат наружу (надеюсь).
Вот неплохой материал есть https://hevodata.com/learn/rabbitmq-vs-activemq/#Understanding-the-Key-Differences. По сути там как говорится про кластеризацию, то о чём мы и писали, что RabbitMQ хорош для сложных сценариев обмена.
Если доберутся руки писать о кейсах, когда лучше применим RabbitMQ, постараемся не забыть про разницу методов обмена сообщениями. P2P. PUB-SUB в ActiveMQ вполне может делать этот инструмент более полезным в каких-то частных кейсах.
Так это просто интересный факт добавлен.
Согласен, нетривиальный кейс. Ничего не обещаю, но попробуем, хотя бы может иностранный кейс хорошо описанный найдём.
Тогда все вопросы к провайдерам managed-решений RabbitMQ, мы при написании статьи отталкивались от их технических материалов.
Спасибо, было в планах отдельную статью по вариантам использования и кейсам сделать.
Спасибо за ценный комментарий, мы забрали поднятые проблемы в список потенциальных тем по CI/CD. Для DevOps-инженеров, которые уже настраивают CI/CD в ней действительно нет нового. В этом материале план и был пройтись по основам.
Казалось бы материалов и так есть немало, но идеальных материалов не бывает. Одна статья глубже, другая понятней, в третьей описаны нюансы.
По собесам точно могу посоветовать посмотреть запись уже нашего недавнего вебинара, там в целом о работе SRE в разных компаниях и в том числе о собесах говорили немного: https://youtu.be/Cj9yKoF6hd0.
Спасибо за интересный вопрос, спрошу у спикеров курса, а так сходу могу сказать, что есть Response от Monzo, инженеры из Dodo рассказывали, что допиливали этот опенсорс, а в Wargaming`е переписывали Jira.
Спасибо! Ограничений нет, все, кто захочет могут зарегистрироваться.
Спасибо за вопрос, бесплатную практику для прохождения курса мы организуем с Mail.ru Cloud Solutions и спикеры будут показывать на примере MCS. При этом делать / не делать практику, попробовать работать в другом облаке на усмотрение участника можно, чисто технически реально часть практик сделать, это от вас зависит, но спикеры рекомендуют на MCS.
Ой, тут очень большая тема. Я могу дать ссылку на документацию https://postgrespro.ru/docs/postgresql/13/ddl-partitioning. Ограничений много. Но с каждой новой версии PostgreSQL что-то да улучшается в секционировании. В данном кейсе использовалось расширение partman об этом тут: https://pgxn.org/dist/pg_partman/doc/pg_partman.html
Спасибо за хороший вопрос, делюсь ответом Ивана:
Если у вас есть таблица с инкрементальным номером, то проблем вытащить данные не будет. Да выполняем команду insert into … select from where id between A and B Но у нас id был uuid. Поэтому мы потратили больше времени на вытаскивания данных – из-за этого было и время остановки сервера больше. Сначала я пробовал сделать так insert into … select from where ctid in ();
Об ctid тут https://postgrespro.ru/docs/postgresql/13/ddl-system-columns
Вытащил так примерно 70 процентов записей. Но потом пришлось пойти по-другому. Я нашел связанную таблицу по внешнему ключу (тут главное условие, что все данные из целевой таблицы точно должны быть в связанной таблице). И начал перебирать uuid из второй таблицы и подставлять в условие where. Так я вытащит все остальные записи.
По блокам.
Да вначале формировал блоки из 10 тыс. значений в запросе where id in (). Находит запросы, которые повисли. Вызывал повторно эти запросы, но блок уменьшал до 100 записей. Потом выискивал опять эти блоки и перебирал по 1 записи. Так и вышел на 17 битых записей.
Внешнего ключа не было. Так как и items и history были секционированы. Так как секционирование было сделано через наследование, то внешние ключи нельзя создать на родительской таблице. А когда делали секционирование таблицы items, то забыли сделать первичный ключ. Поэтому через какое-то время появилась описанная ситуация.
Спасибо за хороший вопрос, делюсь ответом Ивана:
Да вы правы, можно было выставить данный параметр. В данном кластере этот параметр имел значение по умолчанию, те отсутствия таймаута. После данного инцидента он был выставлен в 1 час.
Но я в своей практики видел, когда данным параметром стреляли себе в ногу. Из-за того, что приложение написано не оптимально (что и выше кстати тоже), при выполнении длительного бизнес процесса (длительность доходила до суток) оно работало в одной транзакции. Спасало и БД и приложение, то что пользователей было немного и бизнес процессы работали с разными данными. Но как только мы выставили данный параметр в 1 час, у нас перестало работать приложение. Но так как приложение было большой монолит и переписать его не имело возможности. Поэтому после несколько часов не_работы приложения, данный параметр вернули в значение по умолчанию.
Спасибо за коммент. Мы однозначно хотим доносить до аудитории Хабра о курсах, не скрываю такого умысла. И наш контент иногда связан с курсами.
А этот перевод так точно связан, это можно сказать, отчасти запрос тех, кто проходил первый интенсив по Terraform. Материалов на русском по Terragrunt довольно немного, поэтому мы искали что-нибудь полезное и практическое для перевода.
Спасибо за дополнение. С такими комментами статья становится много полезней.