какие способы помогают избежать взаимных блокировок в транзакциях в mysql

Блокировки и уровни изоляции транзакций InnoDB в MySQL

Здравствуй, Хабр!
Предлагаю всем желающим вспомнить или познать суть блокировок движка InnoDB в MySQL.

КДПВ: deadlock в исполнении тропической фауны

Базовые понятия

Все, думаю, уже знают, что InnoDB использует блокировки на уровне строк. В зависимости от уровня изоляции транзакции могут блокироваться как строки, попавшие в результирующую выборку, так и все строки, что были просмотрены при поиске. Например, в REPEATABLE READ блокирующий запрос без использования индекса потребует перебора всей таблицы, а следовательно и блокировки всех записей. Посему помни, %username%, правильный выбор индексов напрямую влияет на скорость работы блокировок.

Если наложенная на строку блокировка не позволяет выполнить операцию, то транзакция просто ждет снятия мешающей блокировки. В случае перекрестных блокировок ждать можно долго, это deadlock. В документации MySQL есть пара советов о том, как избежать взаимных блокировок.

Все описанное выше определяется InnoDB неявно, вам нужно лишь представлять, что происходит «под капотом».
О том какие именно запросы накладывают блокировки, можно посмотреть опять же в документации.

Ну и перед тем как перейти к уровням изоляции, рассмотрим понятие согласованного чтения (consistent read).
В момент первого запроса в транзакции создается снэпшот данных БД (т.н. read view), на который не влияют изменения в параллельных транзакциях, но влияют изменения в текущей. Чтение из такого снэпшота называют неблокирующим согласованным чтением. Неблокирующим — потому что для создания такого снэпшота не требуется навешивание блокировок, согласованным — потому что никакие катаклизмы во внешним мире (кроме DROP TABLE и ALTER TABLE) не повлияют на уютный мирок снэпшота. InnoDB можно попросить сделать снэпшот и до первого запроса в транзакции, для этого нужно упомянуть об этом во время старта транзакции — START TRANSACTION WITH CONSISTENT SNAPSHOT.

Уровни изоляции транзакций InnoDB

Уровень изоляции можно изменить запросом SET [GLOBAL | SESSION] TRANSACTION ISOLATION LEVEL.

REPEATABLE READ (значение по умолчанию)

READ COMMITED

READ UNCOMMITED (самый слабый уровень)

SERIALIZABLE (самый строгий уровень)

One more thing.

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

SELECT… LOCK IN SHARE MODE — блокирует считываемые строки на запись.
Другие сессии могут читать, но ждут окончания транзакции для изменения затронутых строк. Если же в момент такого SELECT’а строка уже изменена другой транзакцией, но еще не зафиксирована, то запрос ждет окончания транзакции и затем читает свежие данные. Данная конструкция нужна, как правило, для того чтобы получить свежайшие данные (независимо от времени жизни транзакции) и заодно убедиться в том, что их никто не изменит.

SELECT… FOR UPDATE — блокирует считываемые строки на чтение. Точно такую же блокировку ставит обычный UPDATE, когда считывает данные для обновления.

Обратите внимание, что такие запросы читают уже не из снэпшота, как простой SELECT, т.е. они увидят изменения зафиксированные другой транзакцией после начала текущей. Так происходит потому, что InnoDB может заблокировать только последнюю версию строки, а в снэпшоте она не обязательно будет последней.

Например, в сценарии считать → изменить → записать обратно между считать и записать параллельная транзакция может изменить данные, но это изменение будет тут же затерто текущей транзакцией при записи обратно. LOCK IN SHARE MODE в данном примере не даст вклиниться соседней транзакции, ей придется подождать. Заметьте, что в данном случае блокировка будет ставиться дважды, сначала совместная блокировка при чтении, затем исключительная при записи. Так как блокировок две, то есть теоретический шанс проскочить третьей между ними и вызвать deadlock.

Отличие FOR UPDATE в том, что он сразу ставит исключительную блокировку, такую же, как и обычный UPDATE. Таким образом для сценария считать → изменить → записать обратно блокировка будет ставиться только один раз в момент считывания. Такой вариант снизит вероятность возникновения взаимных блокировок.

Источник

Дедлоки в SQL Server — часть 3: Нейтрализуем врага

Борьба с взаимоблокировками

В предыдущей статье мы рассмотрели способы обнаружения и диагностики блокировок.

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

Чтобы избежать взаимоблокировок, или обрабатывать такую ситуацию правильным образом, существует несколько способов. Рассмотрим каждый из них.

Одинаковый порядок обращения к ресурсам

Если взаимная блокировка возникает из-за того, что два процесса обращаются к одним и тем же ресурсам, но в разном порядке, то достаточно поменять порядок блокировки ресурсов. В принципе, если в разных операциях блокируется определенный набор ресурсов, блокироваться первым всегда должен один и тот же ресурс, если это возможно.

В применении к MS SQL этот совет, немного упрощая, можно выразить следующим образом: в разных транзакциях, изменяющих несколько таблиц, первой должна изменяться одна и та же таблица.

Например, у нас есть 2 метода, оперирующих одинаковыми ресурсами.

При параллельном выполнении этих двух транзакций велика вероятность возникновения взаимоблокировки, т.к. обе транзакции оперируют одинаковыми ресурсами, но в разном порядке. Если бы обращение к ресурсам было в одинаковом порядке, например Транзакция 2 выполнялась бы следующим образом:

то взаимоблокировки не случилось бы, т.к. при выполнении первого оператора Update одна из транзакций наткнется на уже заблокированный другой транзакцией ресурс и будет ожидать завершения другой транзакции.

На Рис. 1 мы видим пример рассмотренной взаимоблокировки. На нем видно, что процессы с SPID=52 и 54 взаимно блокированы и процесс с SPID=54, стал жертвой.

На Рис. 2 показано состояние возникновения взаимоблокировки. Здесь мы видим, что процесс 52 ждет освобождения ресурса от процесса 54, а процесс 54 ждет освобождения ресурса процессом 52.

Добавление необходимых и правильных индексов

В распределенных системах очень важно создавать правильные индексы, для того чтобы не блокировались лишние ресурсы. Например, если поиск в таблице происходит по некоторому полю и для этого поля отсутствует индекс, то блокировка может быть наложена на всю таблицу целиком, а при наличии индекса, блокируется соответствующий индекс. Поэтому при разработке схемы БД необходимо тщательно подойти к вопросу о создании и добавлении правильных индексов.

Предположим, что у нас есть таблица Students

Таблица не содержит индекса по полю Age.

Допустим параллельно выполняется 2 транзакции

Если у нас нет индекса по полю Age, то две транзакции взаимно заблокируют друг друга.

На Рис. 4 видно, как два процесса (SPID 52 и 54) взаимно заблокировали друг друга и одна из них (SPID 54) стала жертвой менеджера блокировок.

На Рис. 5 показана взаимная блокировка процессов 52 и 54.

Превращение Shared блокировки в Exclusive

Это наиболее часто встречаемая взаимная блокировка. Возникает в транзакциях с уровнем изоляции Repeatable read или Serializable следующим образом:

Транзакция 1 читает запись (накладывается S-блокировка).

Транзакция 2 читает эту же запись (накладывается вторая S-блокировка).

Транзакция 1 пытается изменить запись и ждет, когда транзакция 2 закончится и отпустит свою S-блокировку, чтобы наложить эксклюзивную блокировку.

Транзакция 2 пытается изменить эту же запись и ждет, когда транзакция 1 закончится и отпустит свою S-блокировку, чтобы наложить уже в свою очередь свою эксклюзивную блокировку.

Для возникновения подобной взаимной блокировки достаточно одного ресурса, за который борются две однотипные транзакции (вызов одного и того же метода в параллельных потоках/процессах). Борьба может вестись не только за одну запись, но и за любой другой ресурс. Например, если две Serializable транзакции считают количество записей с определенным значением, а потом вставляют запись с таким же значением, то ресурсом, освобождение которого они ждут, будет ключ в индексе. Эта проблема решается наложением блокировки обновления UPDLOCK на выбираемые данные:

На Рис. 6 показана возникшая взаимоблокировка. На Рис. 7 мы видим, что S блокировка процессов 52 и 53 была сконвертирована в X блокировку. Но они не могут завершиться, т.к. ожидают освобождения ресурса, заблокированного друг другом.

Проверка на наличие перед вставкой

Если в транзакции с уровнем изоляции Serializable попытаться выбрать несуществующее значение (и эта колонка входит в индекс), то будет наложена shared блокировка на все ключи между двумя ближайшими значениям, которые есть в таблице.

Например, если в базе есть записи с и (Id — первичный ключ в таблице), и нет ни одного значения между ними, то при выполнении

будет наложена Shared блокировка на ключи с 15 до 1025. Если до вставки другая транзакция проверит, есть ли пользователь с и попытается его вставить, то произойдёт взаимная блокировка.

Эта проблема решается также как и в выше описанном примере — надо использовать блокировку обновления UPDLOCK:

Таким образом, транзакция, при попытке выполнения оператора SELECT, будем ждать освобождения наложенных другими транзакциями блокировок обновления.

Повтор транзакции

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

Методом DoActionWithRetryAfterDeadlock мы оборачивали все обращения к БД. В случае возникновения взаимоблокировки, MS SQL Server принудительно завершает одну из транзакций и генерирует ошибку. На прикладном уровне мы перехватываем эту ошибку и делаем повтор транзакции. Обычно при повторе транзакции, она успешно выполняется. Если же после нескольких повторных выполнений транзакции, не удается успешно завершить транзакцию, то генерируем ошибку на прикладном уровне. Если ошибки взаимной блокировки все равно появляются, даже при повторных транзакциях, то это может говорить об ошибке в архитектуре приложения или структуре SQL запросов. Здесь необходимо проанализировать запросы к БД, пересмотреть архитектуру бизнес-логики и выполняемых операций таким образом, чтобы избежать возникновения взаимоблокировок.

Минусом такого подхода является то, что он может скрыть реальные проблемы. Поэтому, чтобы этого не допустить, мы ввели метрики взаимоблокировок, которые рассмотрим далее.

Сбор метрик взаимоблокировок

Количественные показатели взаимоблокировок, возникающих в продукте очень важны для диагностики проблем и своевременной реакции на них. В нашем ПО мы используем встроенный в Windows механизм счетчиков производительности для сбора и отображения следующих показателей:

– количество, возникших в продукте взаимоблокировок;

– скорость возникновения взаимоблокировок.

Технически, подсчет данных метрик осуществляется вызовом отдельного метода TotalOperationDeadlockRetries, в котором происходит подсчет показателей взаимоблокировок.

Для подсчета показателей, этот метод должен быть вызван каждый раз при возникновении взаимоблокировки, которая определяется в обработчике ошибок на уровне слоя БД, анализом кодов ошибок, возвращаемых сервером БД:

Таким образом, мы фиксируем и следим за возникающими взаимоблокировками и своевременно реагируем на их появление, при необходимости.

Заключение

В данной статье мы рассмотрели наиболее популярные виды взаимоблокировок и как с ними бороться:

– использовать одинаковый порядок обращения к ресурсам;

– добавлять необходимые индексы в таблицы, чтобы блокировать строки вместо всей таблицы;

– использовать блокировку обновления UPDLOCK при превращение Shared блокировки в Exclusive.

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

Также рассказали о сборе метрик — в своих продуктах мы используем подсчет количества и скорости возникновения взаимоблокировок, чтобы оперативно реагировать на потенциальные проблемы.

Послесловие

В этой серии статей мы хотели поделиться своим опытом использования блокировок в БД при разработке высоконагруженных систем и рассказать, какие проблемы этим решали. Рассмотрели наиболее популярные виды взаимоблокировок и как с ними бороться.

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

Возможно, и Вам приходилось сталкиваться с подобными проблемами, и данная статья поможет в их решении.

Автор статьи: Николай Иванов, Старший Разработчик, ITA Labs

Источник

[Конспект] Про блокировки и транзакции в MySQL

Oct 4, 2018 • zinvapel

В этом посте я хотел бы собрать воедино информацию о блокировках и транзакциях в MySQL.

Блокировки

Типы блокировок

Стратегии блокировок

Блокировки в InnoDB:

InnoDB использует блокировки на уровне строк. В зависимости от уровня изоляции транзакции могут блокироваться как строки, попавшие в результирующую выборку, так и все строки, что были просмотрены при поиске. Например, в REPEATABLE READ блокирующий запрос без использования индекса потребует перебора всей таблицы, а следовательно и блокировки всех записей.

Есть два базовых типа блокировок:

Если копнуть глубже, то выяснится, что есть еще 2 типа блокировок, назовем их блокировками «о намерениях». Нельзя просто так взять и заблокировать запись в InnoDB. Блокировки intention shared и intention exclusive являются блокировками на уровне таблицы и блокируют только создание других блокировок и операции на всей таблице типа LOCK TABLE. Наложение такой блокировки транзакцией лишь сообщает о намерении данной транзакции получить соответствующую совместную или исключительную блокировку строки.

InnoDB накладывает блокировки не на сами строки с данными, а на записи индексов. Та или иная блокировка может накладываться на:

Блокировка промежутков нужна для того, чтобы избежать появления фантомных записей, когда, например, между двумя одинаковыми чтениями диапазона соседняя транзакция успевает вставить запись в этот диапазон.

SELECT… LOCK IN SHARE MODE — блокирует считываемые строки на запись.

Другие сессии могут читать, но ждут окончания транзакции для изменения затронутых строк. Если же в момент такого SELECT’а строка уже изменена другой транзакцией, но еще не зафиксирована, то запрос ждет окончания транзакции и затем читает свежие данные. Данная конструкция нужна, как правило, для того чтобы получить свежайшие данные (независимо от времени жизни транзакции) и заодно убедиться в том, что их никто не изменит.

SELECT… FOR UPDATE — блокирует считываемые строки на чтение. Точно такую же блокировку ставит обычный UPDATE, когда считывает данные для обновления.

Взаимоблокировки (deadlock) возникают тогда, когда две и более транзакции взаимно удерживают и запрашивают блокировку одних и тех же ресурсов, создавая циклическую зависимость. InnoDB обрабатывает взаимоблокировки откатом той транзакции, которая захватила меньше всего монопольных блокировок строк (приблизительный показатель легкости отката). Нельзя справиться с взаимоблокировками без отката одной из транзакций, частичного либо полного.

Транзакции в MySQL

Если вы используете транзакционные и нетранзакционные таблицы (например, таблицы InnoDB и MyISAM) в одной транзакции, то все будет работать хорошо, пока не произойдет что-то неожиданное, откатить данные из нетранзакционных таблиц невозможно.

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

База данных должна всегда переходить из одного непротиворечивого состояния в последующее.

Результаты транзакции обычно невидимы другим транзакциям, пока она не закончена.

Будучи зафиксированы, внесенные в ходе транзакции изменения становятся постоянными. Это означает, что изменения должны быть записаны так, чтобы данные не могли быть потеряны в случае сбоя системы.

Уровни изоляции транзакций

Проблемы параллельного доступа с использованием транзакций:

Уровни изоляции:

Конкретная реализация каждого уровня изоляции определяется подсистемой хранения данных MySQL.

Уровни изоляции InnoDB

Журнал транзакций

Ведение журнала помогает сделать транзакции более эффективными. Вместо обнов­ления таблиц на диске после каждого изменения подсистема хранения данных может изменить находящуюся в памяти копию данных. Это происходит очень быстро. Затем подсистема хранения запишет сведения об изменениях в журнал транзакции, который хранится на диске и поэтому долговечен. Это тоже доволь­но быстрая операция, поскольку добавление событий в журнал сводится к опе­рации последовательного ввода/вывода в пределах ограниченной области диска вместо случайного ввода/вывода в разных местах. Позже процесс обновит табли­цу на диске.

MVCC сохраняет мгновенный снимок состояния данных в определенный момент времени.

InnoDB реализует MVCC, сохраняя вместе с каждой строкой два скрытых значения, которые показывают, когда строка была создана и когда истек срок ее хранения (или она была удалена). Вместо хранения фактического момента времени, когда произошли данные события, строка хранит номер версии системы для этого момента.

Применение для Repeatable Read:

Источник

Немного про Deadlock

Это совсем краткий пост о причинах возникновения Deadlock

В более менее нагруженных проектах, использующих транзакции InnoDB, в любой момент может возникнуть ошибка вида

«Deadlock found when trying to get lock; try restarting transaction»

Главное не паниковать при виде этих страшных слов, сейчас мы разберемся почему это происходит.

Немного о типах блокировок

В оффициальной документации Mysql про типы блокировок написано совсем немного, а именно:

Есть 2 типа блокировок — Shared (S) и Exclusive (X). Первый тип позволяет только читать данные прикрытые этой блокировкой, второй — читать, писать, удалять и (о чем скромно умолчали) — получить блокировку уровня S

Так же сказано что если Транзакция№1 владеет блокировкой типа S на строке r, то другая Транзакция№2 может захватить эту блокировку. Чтобы получить блокировку типа X на этой строке, второй транзакции придется тихо подождать в сторонке.

Если же Транзакция№1 владеет блокировкой типа X на строке r, то Транзакция№2 не может ни захватить эту же блокировку, ни получить новую уровня S. Она опять тихо идет и ждет пока Транзакция№1 освободит требуемую строку.

Здесь есть один важный момент, который необходимо усвоить: блокировки S и X — это 2 разные блокировки. Это не значит что блокировка S, это какое-то подмножество блокировки X. Это две разных сущности.

Вернемся к дедлокам. На некоторых форумах я встречал вопросы «Как получит deadlock в Mysql». На самом деле очень просто.

Все необходимы ингредиенты у нас имеются в наличии: две транзакции, блокировки типа S и X и строка, на которую получают блокировки.

Краткий рецепт приготовления deadlock на одной строке
1) Транзакция№1 получает блокировку S и продолжает работу
2) Транзакция№2 пытается получить блокировку типа X и… начинает ждать когда Транзакция№1 освободит блокировку S
3) Транзакция№1 пытается получить блокировку типа X и… начинает ждать когда Транзакция№2 получит блокировку типа X и освободит её

Тут есть один скользкий момент. Казалось бы что мешает Транзакции№1 получить блокировку X если она уже имеет блокировку S на этой же строке. А мешает то о чем мы говорили
1) Во-первых X и S это две разных блокировки
2) Во-вторых блокировка типа S не дает право на получение блокировки типа X. Никаких привилегий — в очередь!

Код для ситуации выше

Как же с этим бороться? Офф. сайт Mysql советует комититься почаще, а так же перепроверять код ошибки и перепроводить откатившуюся транзакцию. Мне кажется есть вариант получше — сразу получать блокировку типа X. Тогда на третьем шаге нашего рецепта Транзакция№1 смогла бы получить свою законную блокировку и спокойно завершиться

Напоследок скажу что определить причину deadlock поможет команда SHOW ENGINE INNODB STATUS, которая показывает какие блокировки кто держит и какие ожидает

Источник

Как избежать взаимоблокировок СУБД MySQL ‘при попытке получить блокировку; попробуйте перезапустить сделки

у меня есть таблица innoDB, которая записывает онлайн-пользователей. Он обновляется при каждом обновлении страницы пользователем, чтобы отслеживать, на каких страницах они находятся, и их последнюю дату доступа к сайту. Затем у меня есть cron, который запускается каждые 15 минут для удаления старых записей.

я получил «тупик, найденный при попытке получить блокировку; попробуйте перезапустить транзакцию» около 5 минут прошлой ночью, и, похоже, это происходит при запуске вставок в эту таблицу. Может кто-нибудь подсказать, как этого избежать ошибка?

вот запросы, которые выполняются:

первый визит на сайт:

на каждой странице обновить:

Cron каждые 15 минут:

затем он делает некоторые подсчеты для регистрации некоторых статистических данных (т. е.: участники онлайн, посетители онлайн).

6 ответов:

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

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

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

будет невозможно получить тупик.

Так вот что я предлагаю:

убедитесь, что у вас нет другого запросы, которые блокируют доступ к нескольким ключам одновременно, за исключением инструкции delete. если вы делаете (и я подозреваю, что вы делаете), упорядочить их где в (k1, k2. kn) в порядке возрастания.

исправьте оператор delete для работы в порядке возрастания:

еще одна вещь, чтобы иметь в виду, что документация mysql предполагает, что в случае тупика клиент должен повторить попытку автоматически. вы можете добавьте эту логику в клиентский код. (Скажем, 3 попытки на эту конкретную ошибку, прежде чем сдаваться).

взаимоблокировка происходит, когда две транзакции ждут друг друга, чтобы получить блокировку. Пример:

есть множество вопросов и ответов о взаимоблокировках. Каждый раз, когда вы вставить/обновить или удалить строку, а блокировка. Чтобы избежать взаимоблокировки, необходимо убедиться, что параллельные транзакции не обновляют строку в порядке, который может привести к взаимоблокировке. Вообще говоря, попробуйте получить блокировку всегда в том же порядке даже в разных транзакциях (например, всегда сначала таблица A, затем таблица B).

еще одна причина тупика в базе данных может быть отсутствующих индексов. Когда строка вставлена/обновлена / удалена, база данных должна проверить реляционные ограничения, то есть убедиться, что отношения согласованы. Для этого база данных должна проверить внешние ключи в связанных таблицах. Это может результат в другом замке быть приобретено, чем строка, которая была изменена. Убедитесь, что у вас всегда есть индекс на внешних ключах (и, конечно же, первичные ключи), иначе это может привести к таблица блокировок вместо блокировку строки. Если происходит блокировка таблицы, конфликт блокировки выше и вероятность взаимоблокировки увеличивается.

для начало может быть стоит попытаться явно получить блокировку таблицы сразу для инструкции delete. Смотрите ЗАБЛОКИРОВАТЬ ТАБЛИЦЫ и проблемы с блокировкой таблицы.

вы можете попробовать, что delete работа выполняется путем первой вставки ключа каждой строки, подлежащей удалению, в временную таблицу, подобную этому псевдокоду

кроме того, изменить свой select запросы, чтобы добавить where предложение, исключающее строки старше 900 секунд. Это позволяет избежать зависимости от задания cron и позволяет перепланировать его для запуска меньше часто.

теория о тупиках: у меня нет большого фона в MySQL, но здесь идет. Элемент delete будет держать ключ-диапазон блокировки для datetime, чтобы предотвратить строки, соответствующие его where предложение от добавления в середине транзакции, и поскольку он находит строки для удаления, он попытается получить блокировку на каждой странице, которую он изменяет. Элемент insert собирается получить блокировку на странице, которую он вставляет, и затем попытка получить ключ замок. Обычно insert будет терпеливо ждать, что ключ блокировки, чтобы открыть, но это будет тупик, если delete пытается заблокировать ту же страницу insert использует, потому что delete нужна эта блокировка страницы и insert нужен этот ключевой замок. Это не кажется правильным для вставок, хотя, delete и insert используют диапазоны datetime, которые не перекрываются, поэтому, возможно, что-то еще происходит на.

для Java-программистов, использующих Spring, я избежал этой проблемы, используя аспект AOP, который автоматически повторяет транзакции, которые запускаются в переходные тупики.

посмотреть @RetryTransaction javadoc для получения дополнительной информации.

У меня есть метод, внутренности которого завернуты в MySqlTransaction.

проблема тупика появилась для меня, когда я запустил тот же метод параллельно с собой.

не было проблемы с запуском одного экземпляра метода.

когда я удалил MySqlTransaction, я был в состоянии запустить метод параллельно с самим собой без проблем.

просто делюсь своим опытом, я ничего не пропагандирую.

Источник