Цікаво було б дізнатись, чи не було у вас проблем з реплікацією. Якщо були, як вирішувалось. Маючи однопоточну реплікацію на одну БД в мускулі при частих Update/Insert/Delete слейви тупо не встигають жерти логи і опрацьовувати.
Ну з зростанням пам’яті тут спірно. Якщо у вас order або group тепер не частині індексу, у вас буде tmp table. Разом з зростанням виконання часу запиту виростає кількість коннектів які роблять цю операцію.
Дякую за відгук! Все здобувається на досвіді, і добре — якщо на чужому)) max_execution_time нажаль саме в MariaDB відсутній, але маємо плани винести довгі квері на репліку та обмежити читання на мастері до коротких значень, так
Так, звісно, цей момент дуже поширений. Але сам по собі він не причинить зростання памʼяті, хіба як наслідок, описаний мною — довгі квері. Але причин довгих запитів ще набагато більше, тому не став це включати.
Щоб робити те ж саме «на конвейрі» парою команд, можна поставити proxmox і клонувати LXC під кожний деплоймент. Бонусом будуть бекапи, примитивный моніторинг...
Я б у перелік причин ще додав зміну обраних індексів, якщо не юзати force index. Були цікаві історії, коли mysql вирішував не юзати індекс, або юзати інший. Там відразу починались і тупняки, і ріст конекшенів, і все що завгодно.
Дякую за статтю. Так, в моніторінг History list length — це обов’язково. Першим чином це додаю :). Ще можна встановити max_execution_time для запобігання занадто довгих SELECT.
Коментарі