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

да

все понял, удачи

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

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

хоть и немного дороже 🙂

если нагрузка распределяется приложением - должен быть service discovery, подключи третий сервер слейвом и прогони на  нем, потом переключи кластер на него

тут как-бы задача типичная, alter при выкладке без bc break, не понимаю в чем проблема - добавь места, если надо 🙂

@Adelf32 @svetsmirnova забаньте @ Angelinalay plz - спаммер про биткоины

Done

Всем привет!
Подскажите, куда копать?
Есть 2 таблицы по 200К записей всего. Самый простой left join без ограничений выполняется по 3-4 сек. Индексы прописаны и используются, сервер 4 ядра, 8ГБ оперативы. Версия Percona Server (GPL). Release 10. Версия mysql 8.0.19-10

Это пока тестовый сервер, нагрузки другой нет никакой

query_cache_size в 8-ой версии уже не выставить

Обе таблицы InnoDB

покажи explain analyze

Limit: 10 row(s) (no early end due to SQL_CALC_FOUND_ROWS)  (actual time=0.247..8549.401 rows=10 loops=1)
-> Group (no aggregates)  (actual time=0.235..8094.313 rows=182728 loops=1)
-> Nested loop inner join  (cost=80854.10 rows=178198) (actual time=0.181..6889.122 rows=182728 loops=1)
-> Index scan on products using PRIMARY  (cost=18484.80 rows=178198) (actual time=0.126..909.123 rows=182728 loops=1)
-> Index lookup on products_categories using pt (product_id=products.product_id)  (cost=0.25 rows=1) (actual time=0.013..0.019 rows=1 loops=182728)

а можете запрос показать?

SELECT
 SQL_CALC_FOUND_ROWS
 products.product_id,
 products.product_type,
 products.parent_product_id
FROM
 cscart_products as products
INNER JOIN
 cscart_products_categories as products_categories
   ON products_categories.product_id = products.product_id
GROUP BY products.product_id
ORDER BY products.product_id ASC
LIMIT 0, 10;

причина тормозов - nested loop 182728 элементов