Короче попробовала с другого хоста видео по прямой ссылке скачать, получилось.
Что-то не то с traceroute до меня.
На моей машине (где ничего не работает):
sveta@thinkie:~> sudo traceroute 967101250.r.worldcdn.net
root's password:
traceroute to 967101250.r.worldcdn.net (93.191.8.230), 30 hops max, 60 byte packets
1 192.168.0.1 (192.168.0.1) 1458.635 ms 1458.732 ms 1459.115 ms
2 93.155.1.138 (93.155.1.138) 1497.920 ms 1501.072 ms 1501.912 ms
3 81.212.77.53.static.turktelekom.com.tr (81.212.77.53) 1505.453 ms 1511.484 ms 1518.139 ms
4 81.212.25.221.07-antalya-t2-2.07-kiziltoprak-t3-1.statik.turktelekom.com.tr (81.212.25.221) 1512.023 ms 1518.274 ms 1518.259 ms
5 * * *
6 * * *
7 212.156.141.52.306-mil-col-2.06-ebgp-ulus1-k.statik.turktelekom.com.tr (212.156.141.52) 113.439 ms 114.352 ms 115.087 ms
8 81.25.202.221 (81.25.202.221) 108.853 ms mno-b2-link.telia.net (213.248.83.177) 111.769 ms 114.527 ms
9 ffm-bb2-link.telia.net (62.115.142.148) 125.676 ms ffm-bb2-link.telia.net (62.115.134.38) 147.564 ms ffm-bb2-link.telia.net (62.115.142.150) 119.197 ms
10 s-bb4-link.telia.net (62.115.112.97) 138.024 ms 125.621 ms s-bb4-link.telia.net (62.115.139.99) 126.026 ms
11 ae-3.r02.frnkge04.de.bb.gin.ntt.net (129.250.4.54) 106.287 ms hls-b2-link.telia.net (62.115.113.93) 135.167 ms ae-5.r21.frnkge03.de.bb.gin.ntt.net (129.250.4.162) 102.385 ms
12 fiord-ic-309637-mow-b4.c.telia.net (80.239.195.66) 147.306 ms 83.231.214.42 (83.231.214.42) 144.401 ms fiord-ic-309637-mow-b4.c.telia.net (80.239.195.66) 145.423 ms
13 kiev-nt-b1-ae22-vlan3878.fiord.net (62.140.245.165) 161.748 ms uzhgorod-atr-b1-xe0-0-3-vlan2035.fiord.net (80.77.167.26) 147.274 ms kiev-nt-b1-ae22-vlan3878.fiord.net (62.140.245.165) 161.829 ms
14 93-191-8-230.fiord.ru (93.191.8.230) 165.925 ms kiev-nt-b1-xe2-3-0-vlan2036.fiord.net.ua (62.140.245.230) 143.136 ms 93-191-8-230.fiord.ru (93.191.8.230) 148.622 ms
sveta@thinkie:~> ping 967101250.r.worldcdn.net -c 3
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=49 time=150 ms
64 bytes from 93-191-8-230.fiord.ru (93.191.8.230): icmp_seq=2 ttl=49 time=151 ms
64 bytes from 93-191-8-230.fiord.ru (93.191.8.230): icmp_seq=3 ttl=49 time=153 ms
--- 967101250.r.worldcdn.net ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2002ms
rtt min/avg/max/mdev = 150.957/151.977/153.724/1.281 ms
На машине где нормально грузится:
sveta:~$ traceroute 967101250.r.worldcdn.net
traceroute to 967101250.r.worldcdn.net (83.222.114.44), 30 hops max, 60 byte packets
1 10.10.8.2 (10.10.8.2) 0.140 ms 0.288 ms 0.380 ms
2 rst-core03.blackmesh.com (74.121.199.226) 0.758 ms 1.054 ms 1.232 ms
3 rst-c05-t5-4-10g.blackmesh.com (74.121.197.145) 0.480 ms 0.559 ms 0.633 ms
4 ash-b2-link.telia.net (62.115.50.117) 2.776 ms 2.886 ms 3.127 ms
5 ash-bb4-link.telia.net (213.155.136.38) 1.066 ms ash-bb4-link.telia.net (62.115.115.153) 0.941 ms ash-bb4-link.telia.net (213.155.136.38) 1.197 ms
6 nyk-bb2-link.telia.net (80.91.245.99) 7.281 ms nyk-bb2-link.telia.net (213.155.130.74) 46.208 ms nyk-bb2-link.telia.net (62.115.138.28) 7.424 ms
7 kbn-bb4-link.telia.net (213.155.134.53) 98.501 ms kbn-bb4-link.telia.net (62.115.141.104) 98.122 ms 98.282 ms
8 s-bb4-link.telia.net (62.115.139.172) 103.560 ms 103.364 ms s-bb4-link.telia.net (62.115.139.176) 107.722 ms
9 hls-b1-link.telia.net (62.115.142.243) 109.222 ms mow-b4-link.telia.net (80.91.253.219) 126.760 ms mow-b4-link.telia.net (80.239.147.158) 125.804 ms
10 sap-b3-link.telia.net (213.155.133.81) 116.027 ms mnogobyte-ic-309341-mow-b4.c.telia.net (62.115.51.14) 129.438 ms 128.724 ms
11 ip-core.mnogobyte.net (77.220.167.242) 126.966 ms 123.494 ms mow-b3-link.telia.net (80.91.247.208) 126.529 ms
12 ip-core.mnogobyte.net (77.220.167.102) 129.994 ms mnogobyte-ic-309341-mow-b4.c.telia.net (62.115.51.14) 128.631 ms ip-core.mnogobyte.net (77.220.167.102) 127.836 ms
13 83.222.114.44 (83.222.114.44) 127.141 ms ip-core.mnogobyte.net (77.220.167.242) 123.874 ms 126.232 ms
sveta:~$ ping 967101250.r.worldcdn.net -c 3
PING 967101250.r.worldcdn.net (93.170.216.11) 56(84) bytes of data.
64 bytes from 93.170.216.11: icmp_seq=1 ttl=53 time=128 ms
64 bytes from 93.170.216.11: icmp_seq=2 ttl=53 time=128 ms
64 bytes from 93.170.216.11: icmp_seq=3 ttl=53 time=128 ms
--- 967101250.r.worldcdn.net ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2000ms
rtt min/avg/max/mdev = 128.819/128.869/128.912/0.038 ms
Параллельности тут не выжмешь. Зато можно снизить нагрузку на 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
Он ещё самый важный с точки зрения сохранности данных
Что-то не то с traceroute до меня.
На моей машине (где ничего не работает):
На машине где нормально грузится:
Строго говоря проблема Олега довольно известна. Другое дело, что в чистом виде она встречается не так часто. Однако в поддержке мы подобное видим достаточно часто.
Что мы советуем для текущих версий?
Во-первых, единственный параметр, который не может здесь играть роли — это 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
Он ещё самый важный с точки зрения сохранности данных