Я вот смог получить 8к при параллельной репликации. Может кто поделиться своими цифрами? 8000 qps при sync_binlog=1 и innodb_flush_log_at_trx_commit=1. При sync_binlog=0 и innodb_flush_log_at_trx_commit=0 было 17000 qps
хз, на моем жестком диске не более 13 qps 😄
Без отставания реплики ?
без реплик, просто я хз как у тебя получается заставить диск делать 8K записей в секунду, мой на 13 штуках 100% загружен чтением и записью 👀
Это не батч инсерт, просто по строчке одной. У меня эти диски, они могут https://gcloud-compute.com/disks.html)
https://www.percona.com/blog/2012/05/16/benchmarking-single-row-insert-performance-on-amazon-ec2/ зависит от структуры таблички, на одном pk можно было и больше, даже 10 лет назад
Ну тут вопрос больше про то, чтобы реплика не отставала. Так можно выжать много.
Если идёт многопоточная вставка и group commit активно работает, то и реплики выдают ту же производительность https://www.percona.com/blog/2018/10/17/can-mysql-parallel-replication-help-my-slave/ Writeset ещё могут помочь. Если нагрузка из больших транзакций, то слейв будет "рывками" работать, то отстаёт, то нет. Ну и обилие вторичных индексов так же бьёт по скорости вставки на слейве
Да, делаю именно так. Заметил такое поведение еще, что на слейве в два раза qps больше чем на мастере. Нагрузка там только моя, лью инсерты в одну строчку. На слейве еще селекты идут в performance схему как я понял из general log.
Обсуждают сегодня