Конференция большая и devroom — ы могут быть разные, зависит от тех, кто их организует. Например, MySQL отличная просто. Была ещё в PostgreSQL, тоже доклады понравились и в прошлом году, и в этом. На что-то другое меня не хватает, к сожалению: полный день в MySQL devroom, во второй хочется и стенды посмотреть, и пообщаться. Поэтому только пара докладов в PostgreSQL и всё. Микрофон в MySQL, кстати, точно был. Не для камеры, а для зала я имею в виду. В PostgreSQL вроде тоже. А по поводу бомжеватого мужичка… Я как-то на стенде MySQL работала. Мы раздавали прикольных роботов, но их было мало, поэтому я всех use case-ы просила рассказывать перед тем как робота отдать. И тут подходит мужичок, просит робота. Я ему: как вы используете MySQL? Он: я охранник, детям хочу подарить =)))
> Я общался с Дмитрием Лёневым как минимум дважды:
Так ты что, результаты тестов только Дмитрию Ленёву послал? Ну вот честно: баг открыть всё-таки нужно было. Просто потому, что все эти частные внутренние переписки «а у моего знакомого вот такие тесты» легко теряются. Особенно если «контакт» даже не в той группе, которая этими вещами занимается.
Если ты не хотел светить тесты их всегда можно отправить скрытым комментом (или скрытым файлом). Или же весь баг сделать скрытым с самого начала (потом, правда, будет практически невозможно повлиять на исправление скрытого бага, не являясь платным клиентом Оракла. Хотя я видела случаи когда человек делал скрытый баг и в тот же день test case публиковал на stackoverflow).
Открывать баги очень важно потому, что их видит не только «контакт из Оракла», но и люди из команды replication (или про что баг), и из поддержки, и из Community. И каждый из этих людей может подумать, что «баг важный, его нужно исправлять» и задействовать доступные внутренние механизмы. А доступа к частному письму у кого-то из них может не быть.
То, что Вы описали выше — это не MIXED, а ROW-based format. Все DDL всегда пишутся в формате statement, независимо от формата логов. Ну в самом деле: какие могут быть изменения строк при изменении метаданных? MIXED работает именно так, как описал symbix
> Помню, что его в какой-то версии включили по умолчанию, но очень быстро это изменили :-)
Это в какой-то 5.1, кажется, было. Дело в том, что тогда это была новая фича и, естественно, не настолько стабильная как старый statement. Сейчас те баги уже давно устранили и MIXED безопасен.
Просто это же зависит от приложения. Например, в одном случае мы можем повторять попытки до бесконечности, в другом до достижения какого-то timeout (или количества попыток как в статье). Соответственно возникает вопрос: почему 10, а не что-то ещё. В независимости в дефайне ли число или hard-coded.
Мне понятно зачем вы это делаете, но всё равно выглядит именно цикл странно. Было бы лучше написать, что транзакцию можно повторить и один из способов сделать это в цикле. Также объяснить почему именно столько повторений и что в другом случае их может быть, например 42
Отсюда вывод — нужно отступать от классической теории реляцонных баз данных, и выделять большие по размеру столбцы (MEDIUMTEXT например) в отдельные таблицы, если данные в них меняются реже, чем остальные атрибуты в этой сущности.
Ну вообще в выделении больших по размеру столбцов в отдельные таблицы я не вижу ничего плохого, окромя хорошего. Особенно если в «основной» таблице у вас много полей. Только к размеру row image в binary log это отношения не имеет. То, чего вы добиваетесь, нужно делать установкой опции binlog-row-image либо в minimal, либо в noblob.
innodb_log_file_size к «подводному камню №3» отношения тоже не имеет. Это не тоже самое, что binary log. И формат лога в данном случае называется ROW, а не MIXED. MIXED значит, что мы всё, что можно, пишем в STATEMENT, а что нельзя — в ROW.
# этот размер выставляем в 50-80% от размера всей оперативной памяти у сервера БД.
innodb_buffer_pool_size = 512M
Этот совет взят из мануала или шаблона конфигурации по умолчанию, но на данный момент ведутся разговоры, что он устарел в связи с резко возросшим количеством памяти на боевых серверах. Правильный совет: innodb_buffer_pool_size дожен вмещать все активные данные (грубо говоря суммарный размер таблиц, которыми вы пользуетесь). И вот если он больше размера доступной памяти, тогда пользоваться правилом 50-80%
> Логическая репликация: она может сломаться в режиме statement-based, если разработчики сделают какие-то «неправильные» запросы с limit (поправьте если это уже не так).
Это так и всегда будет так. В силу того, что некоторые запросы не гарантируют возвращение одного и того же результата при повторном выполнении. В любой базе.
> А row-based означает сильную деградацию в i/o.
А вот это не так. Точнее, было так в 5.5 для запросов вида UPDATE сто миллионов строк WHERE id=12345. В 5.6 для такого ввели опцию, позволяющую указать хотим ли мы записывать в лог все изменения или же только то, что изменилось.
Более того, иногда statement-based означает деградацию IO. Для запросов вида UPDATE IF… THEN… ELSE IF… и так много раз WHERE мы нашли всего одну строку.
Там не всё так просто: нужно ещё shared tablespace переносить. То есть либо вы останавливаете сервер полностью и копируете datadir, либо пользуетесь утилитами горячего копирования (XtraBackup или MySQL Enterprise Backup), либо ручками переносите таблицы по одной при помощи transportable table spaces (доступны в 5.6+). XtraBackup или MySQL Enterprise Backup умеют копировать InnoDB таблицы поштучно.
Ну вот и ответ. В MySQL слейв всегда read-write. Даже когда включена опция read-only суперпользователю разрешается писать.
В принципе можно написать feature request на bugs.mysql.com, чтобы добавили подобную оптимизацию для real read-only слейвов. (Типа как read-only транзакции сделали в 5.6) Проблема только в том, что большинство пользователей MySQL пишут на слейв =(
А сейчас я ниже писала как повысить производительность единственного thread-а. Дополнительно можно понизить transaction isolation level и принудительно включить read only транзакции на слейве для всего, а не только для single-statement select (что по-любому read only в 5.6).
Короче попробовала с другого хоста видео по прямой ссылке скачать, получилось.
Что-то не то с 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
Так ты что, результаты тестов только Дмитрию Ленёву послал? Ну вот честно: баг открыть всё-таки нужно было. Просто потому, что все эти частные внутренние переписки «а у моего знакомого вот такие тесты» легко теряются. Особенно если «контакт» даже не в той группе, которая этими вещами занимается.
Если ты не хотел светить тесты их всегда можно отправить скрытым комментом (или скрытым файлом). Или же весь баг сделать скрытым с самого начала (потом, правда, будет практически невозможно повлиять на исправление скрытого бага, не являясь платным клиентом Оракла. Хотя я видела случаи когда человек делал скрытый баг и в тот же день test case публиковал на stackoverflow).
Открывать баги очень важно потому, что их видит не только «контакт из Оракла», но и люди из команды replication (или про что баг), и из поддержки, и из Community. И каждый из этих людей может подумать, что «баг важный, его нужно исправлять» и задействовать доступные внутренние механизмы. А доступа к частному письму у кого-то из них может не быть.
Это в какой-то 5.1, кажется, было. Дело в том, что тогда это была новая фича и, естественно, не настолько стабильная как старый statement. Сейчас те баги уже давно устранили и MIXED безопасен.
Просто это же зависит от приложения. Например, в одном случае мы можем повторять попытки до бесконечности, в другом до достижения какого-то timeout (или количества попыток как в статье). Соответственно возникает вопрос: почему 10, а не что-то ещё. В независимости в дефайне ли число или hard-coded.
42Ну вообще в выделении больших по размеру столбцов в отдельные таблицы я не вижу ничего плохого, окромя хорошего. Особенно если в «основной» таблице у вас много полей. Только к размеру row image в binary log это отношения не имеет. То, чего вы добиваетесь, нужно делать установкой опции binlog-row-image либо в minimal, либо в noblob.
innodb_log_file_size к «подводному камню №3» отношения тоже не имеет. Это не тоже самое, что binary log. И формат лога в данном случае называется ROW, а не MIXED. MIXED значит, что мы всё, что можно, пишем в STATEMENT, а что нельзя — в ROW.
Этот совет взят из мануала или шаблона конфигурации по умолчанию, но на данный момент ведутся разговоры, что он устарел в связи с резко возросшим количеством памяти на боевых серверах. Правильный совет: innodb_buffer_pool_size дожен вмещать все активные данные (грубо говоря суммарный размер таблиц, которыми вы пользуетесь). И вот если он больше размера доступной памяти, тогда пользоваться правилом 50-80%
всегдапоследние лет 9, что я ей вплотную занимаюсь.Это так и всегда будет так. В силу того, что некоторые запросы не гарантируют возвращение одного и того же результата при повторном выполнении. В любой базе.
> А row-based означает сильную деградацию в i/o.
А вот это не так. Точнее, было так в 5.5 для запросов вида UPDATE сто миллионов строк WHERE id=12345. В 5.6 для такого ввели опцию, позволяющую указать хотим ли мы записывать в лог все изменения или же только то, что изменилось.
Более того, иногда statement-based означает деградацию IO. Для запросов вида UPDATE IF… THEN… ELSE IF… и так много раз WHERE мы нашли всего одну строку.
Ну вот и ответ. В MySQL слейв всегда read-write. Даже когда включена опция read-only суперпользователю разрешается писать.
В принципе можно написать feature request на bugs.mysql.com, чтобы добавили подобную оптимизацию для real read-only слейвов. (Типа как read-only транзакции сделали в 5.6) Проблема только в том, что большинство пользователей MySQL пишут на слейв =(
А сейчас я ниже писала как повысить производительность единственного thread-а. Дополнительно можно понизить transaction isolation level и принудительно включить read only транзакции на слейве для всего, а не только для single-statement select (что по-любому read only в 5.6).
Что-то не то с traceroute до меня.
На моей машине (где ничего не работает):
На машине где нормально грузится: