Параллельности тут не выжмешь. Зато можно снизить нагрузку на CPU. Те же disk writes — они требуют CPU. То есть будет работать также одно ядро, но будет работать меньше.
А теперь главный вопрос: в каком из списков рассылки можно почитать описание проблемы Олега? Ах, ну да, он же никуда и не писал. Но чему тогда удивляться?
Строго говоря проблема Олега довольно известна. Другое дело, что в чистом виде она встречается не так часто. Однако в поддержке мы подобное видим достаточно часто.
Что мы советуем для текущих версий?
Во-первых, единственный параметр, который не может здесь играть роли — это innodb_thread_concurrency. Все остальные performance-related параметры вполне tunable.
Далее, если слейв read-only, можно отключить innodb_doublewrite_buffer, sync_binlog, xa транзакции, поставить innodb_flush_log_at_trx_commit в 0 и сделать ещё ряд подобных вещей, которые, строго говоря, не рекомендуются, так как могут привести к потере данных. Но так как данные у нас есть где-то ещё (а бинарные логи нужноможно бэкапить при помощи mysqlbinlog --raw ..., а не рабочего слейва) — это можно пережить.
Плюс есть ещё параметры типа innodb_io_capacity, которые нужно ставить в то, что написано в мануале (реальную скорость диска), а не от балды и innodb_flush_method, который таки лучше потестировать в конкретном окружении после того, как его выставили в O_DIRECT
Это для слейва, с которого не читают.
Для слейва, с которого активно читают, innodb_thread_concurrency тоже будет работать. Для запросов на чтение.
Я так понимаю, что вы под «бинарной» репликацией имеете в виду, что реплицируется transaction log движка? Как если бы MySQL репликация была построена на InnoDB redo log file (чего нет). С CPU этот вариант, кстати, тоже будет связан. Потому что transaction log нужно будет как-то передать по сети, записать на диск (CPU!) и в каком-то порядке apply (ага, в ту же многопоточность и возможность её реализации упираемся).
В MySQL же отдельный независимый binary log. Я затрудняюсь сказать почему именно так в своё время реализовали. С моей точки зрения это, скорее, плюс, потому что делает репликацию независимой от реализации формата хранения данных. Можно, наверное, и на многодвижковость всё списать (которые тогда были ещй не-pluggable). Или на то, что много лет назад, когда встроенная репликация в MySQL была, а для PostgreSQL существовали только third-party решения, основным движком был MyISAM, у которого нет transaction log вообще.
В MySQL schema — это синоним database. Можно сказать, что в MySQL всего одна база, если сравнивать с PostgreSQL или Oracle. А того, что там схем нет — нельзя.
> Минус правда в том, что зачастую в mysql это единственный реальный способ вытащить какую-то информацию о таблице, т.е. приходится парсить show create table вместо того, чтобы просто посмотреть в нужное место каталога…
Эээ, а что есть в SHOW CREATE TABLE и нет в Information Schema?
Реплика не поспевает не из-за движков, а потому что по умолчанию у неё только один SQL thread. Соответственно InnoDB и прочие не могут полностью утилизировать CPU (при обработке одного лишь SQL thread-а).
Непонятно куда на Универсариуме писать баг. Сегодня ни одно видео не грузится. Люди в комментариях к курсам (я ещё на русскую орфоэпию подписана) советуют пробовать в другом браузере, но у меня именно Network error:
Ничего не знаю как работают в tar или wine, но как послан bug report имеет огромное значение. Вот только сегодня с коллегами обсуждали bugs.mysql.com/bug.php?id=72322 Дело в том, что underlying issue of this bug — это давно известная проблема и я, честно говоря, ожидала фикса в лучшем случае только в следующей major версии. Однако после того, как был сделан report с таким хорошим test case, позволившим взять и повторить баг, это пофиксили не только в future version, но и во всех поддерживаемых. А до этого годами люди слали что-то типа «Information Schema работает медленно».
Свой собственный абзац заслуживает движок таблиц под названием Memory. Особенность этого движка заключается в том, что он не персистирует данные на диск, а хранит целиком в памяти. Количество памяти фиксировано и задается настройкой, которую менять можно только путем перезапуска сервера БД. С эксплуатацией этого движка связано два нюанса:
таблица, вышедшая за предел допустимого размера, моментально “свопится” на диск, карета превращается в тыкву, иногда вместе с базой данных (если движок Memory использовался для оптимизации производительности);
С internal memory tables не путаете:
MEMORY table contents are stored in memory, which is a property that MEMORY tables share with internal temporary tables that the server creates on the fly while processing queries. However, the two types of tables differ in that MEMORY tables are not subject to storage conversion, whereas internal temporary tables are:
If an internal temporary table becomes too large, the server automatically converts it to on-disk storage, as described in Section 8.4.4, “How MySQL Uses Internal Temporary Tables”.
User-created MEMORY tables are never converted to disk tables.
Не, там в другом проблема. То есть в мьютексах, конечно. В момент когда нужно его очистить, в случае, если содержимое таблиц, к которым обращаются хранящиеся в нём запросы, поменялось, он держит глобальный мьютекс и все остальные запросы стоят. Такое особенно заметно при высокой нагрузке и большом размере query cache. А пока он себя обновить не решил — всё многопоточно. Случай мастер-мастера здесь роли не играет. Его фиксили, но недофиксили: там с архитектурой какие-то проблемы. Поэтому лучше просто держать маленьким: 256 MB всяко быстрее обновится, чем 4G.
У Оракла нет имплементации Galera — это совершенно независимый от него продукт.
Federated была разработана ещё в MySQL AB и, к сожалению, до сих пор официально поддерживается. К сожалению, потому что если вы пойдёте на bugs.mysql.com и сравните как быстро устраняются баги, например, репликации и Federated — будет понятно что я имею в виду =)
> Стоит добавить важный с точки зрения производительности параметр skip-innodb_doublewrite
Он ещё самый важный с точки зрения сохранности данных
Строго говоря проблема Олега довольно известна. Другое дело, что в чистом виде она встречается не так часто. Однако в поддержке мы подобное видим достаточно часто.
Что мы советуем для текущих версий?
Во-первых, единственный параметр, который не может здесь играть роли — это innodb_thread_concurrency. Все остальные performance-related параметры вполне tunable.
Далее, если слейв read-only, можно отключить innodb_doublewrite_buffer, sync_binlog, xa транзакции, поставить innodb_flush_log_at_trx_commit в 0 и сделать ещё ряд подобных вещей, которые, строго говоря, не рекомендуются, так как могут привести к потере данных. Но так как данные у нас есть где-то ещё (а бинарные логи
нужноможно бэкапить при помощи mysqlbinlog --raw ..., а не рабочего слейва) — это можно пережить.Плюс есть ещё параметры типа innodb_io_capacity, которые нужно ставить в то, что написано в мануале (реальную скорость диска), а не от балды и innodb_flush_method, который таки лучше потестировать в конкретном окружении после того, как его выставили в O_DIRECT
Это для слейва, с которого не читают.
Для слейва, с которого активно читают, innodb_thread_concurrency тоже будет работать. Для запросов на чтение.
Или попросить кого-нибудь потестировать.Если не забуду: опубликую результаты.А что происходит, если какой-то параллельный процесс на слейве будет читать или писать из/в тех же таблиц?
В MySQL же отдельный независимый binary log. Я затрудняюсь сказать почему именно так в своё время реализовали. С моей точки зрения это, скорее, плюс, потому что делает репликацию независимой от реализации формата хранения данных. Можно, наверное, и на многодвижковость всё списать (которые тогда были ещй не-pluggable). Или на то, что много лет назад, когда встроенная репликация в MySQL была, а для PostgreSQL существовали только third-party решения, основным движком был MyISAM, у которого нет transaction log вообще.
Но вообще смотрите dev.mysql.com/doc/refman/5.7/en/replication-options-slave.html#sysvar_slave_parallel_type Лучше в 5.7, в 5.6 поддерживается только DATABASE.
Он с каждой версией становится всё дешевле и дешевле: dev.mysql.com/doc/refman/5.7/en/innodb-create-index-overview.html
Эээ, а что есть в SHOW CREATE TABLE и нет в Information Schema?
wget 967101250.r.worldcdn.net/video_fragments/3019/mp4/14094%20L1%20P1_360p.mp4
--2015-10-10 20:58:45-- 967101250.r.worldcdn.net/video_fragments/3019/mp4/14094%20L1%20P1_360p.mp4
Resolving 967101250.r.worldcdn.net (967101250.r.worldcdn.net)… 93.191.8.230
Connecting to 967101250.r.worldcdn.net (967101250.r.worldcdn.net)|93.191.8.230|:80… connected.
HTTP request sent, awaiting response…
И висит. Домен пингуется:
ping 967101250.r.worldcdn.net
PING 967101250.r.worldcdn.net (93.191.8.230) 56(84) bytes of data.
64 bytes from 93-191-8-230.fiord.ru (93.191.8.230): icmp_seq=1 ttl=50 time=152 ms
64 bytes from 93-191-8-230.fiord.ru (93.191.8.230): icmp_seq=2 ttl=50 time=151 ms
64 bytes from 93-191-8-230.fiord.ru (93.191.8.230): icmp_seq=3 ttl=50 time=152 ms
С internal memory tables не путаете:
(http://dev.mysql.com/doc/refman/5.6/en/memory-storage-engine.html)
«The table is full» ошибка в пользовательской таблице будет при переполнении.
У Оракла нет имплементации Galera — это совершенно независимый от него продукт.
Federated была разработана ещё в MySQL AB и, к сожалению, до сих пор официально поддерживается. К сожалению, потому что если вы пойдёте на bugs.mysql.com и сравните как быстро устраняются баги, например, репликации и Federated — будет понятно что я имею в виду =)
> Стоит добавить важный с точки зрения производительности параметр skip-innodb_doublewrite
Он ещё самый важный с точки зрения сохранности данных
Про подводные камни, точнее про то, как всё сделать и камней не задеть, есть хорошая книжка «MySQL High Availability».