Вариант для распечатки		Пред. тема | След. тема
Форум Разговоры, обсуждение новостей
Изначальное сообщение		[ Отслеживать ]

"Стабильный релиз СУБД MySQL 8.0"	+/–
Сообщение от opennews (??), 19-Апр-18, 23:30
После двух с половиной лет разработки компания Oracle представила (https://mysqlserverteam.com/whats-new-in-mysql-8-0-generally.../) первый стабильный релиз СУБД MySQL 8.0 (http://dev.mysql.com/doc/relnotes/mysql/8.0/en/).  Версия 8.0 обусловлена сменой нумерации версий, релиз выпущен следом за 5.7 вместо версии 5.8.  Сборки MySQL Community Server 8 сформированы (https://dev.mysql.com/downloads/mysql/) для всех основных дистрибутивов Linux, FreeBSD, macOS и Windows. Ключевые улучшения (http://dev.mysql.com/doc/refman/8.0/en/mysql-nutshell.html) MySQL 8.0: -  Добавлен (https://mysqlserverteam.com/mysql-8-0-announcing-ga-of-the-m.../) режим работы в качестве хранилища документов (Document Store (https://dev.mysql.com/doc/refman/8.0/en/document-store.html)), к которому можно обращаться с использованием методов NoSQL (коллекции JSON (https://dev.mysql.com/doc/refman/8.0/en/document-store-conce...) без предварительно определяемой схемы хранения). Функциональность реализована при помощи плагина mysqlxplugin; -  Добавлены оконные функции (https://dev.mysql.com/doc/refman/8.0/en/window-functions.html) (window-функции или аналитические функции), позволяющие для каждой строки запроса выполнить вычисления, используя строки, связанные с текущей строкой. В отличие от агрегатных функций над сгруппированными строками, которые свёртывают сгруппированный набор строк в одну строку, оконные функции производят (https://mysqlserverteam.com/row-numbering-ranking-how-to-use.../) агрегирование для каждой строки в результирующем наборе. Реализованы как специальные оконные функции RANK, LAG, ROW_NUMBER, FIRST_VALUE, LEAD, LAG  и NTILE, так как возможность применение некоторых агрегатных функций в форме оконных (например, COUNT, SUM, AVG, MIN, MAX); -  Поддержка рекурсивных и не рекурсивных обобщённых табличных выражений (Common Table Expression (https://dev.mysql.com/doc/refman/8.0/en/with.html)), позволяющих (http://mysqlserverteam.com/mysql-8-0-1-recursive-common-tabl.../) использовать временные именованные результирующие наборы , задаваемые при помощи оператора WITH; -  В InnoDB добавлена (https://mysqlserverteam.com/mysql-8-0-1-using-skip-locked-an.../) поддержка опций NOWAIT и SKIP LOCKED, которые можно использовать для управления поведением при наличии блокировок в момент выполнения выражений "SELECT ... FOR SHARE" и "SELECT ... FOR UPDATE". При указании NOWAIT управление будет возвращено сразу с выводом ошибки, если запрошенная строка заблокирована другой транзакцией, а  при "SKIP LOCKED" заблокированные строки будут исключены из результирующего набора;-  Поддержка невидимых индексов (Invisible Indexes (https://dev.mysql.com/doc/refman/8.0/en/invisible-indexes.html), которые никогда не используются оптимизатором. Управление видимостью индекса производится при помощи ключевых слов VISIBLE и INVISIBLE. Обычный видимый индекс может быть превращён в невидимый и наоборот. Невидимые индексы можно использовать для тестирования влияния того или иного индекса на производительность, без физического удаления данного индекса (индекс можно перевести в режим невидимого, изучить изменение производительности и вернуть обратно); -  Поддержка нисходящих индексов (descending indexes (https://dev.mysql.com/doc/refman/8.0/en/descending-indexes.html)), позволяющих (http://mysqlserverteam.com/mysql-8-0-labs-descending-indexes.../) использовать оператор "DESC" при определении индекса для сохранения значений ключей в порядке убывания. В работе подобные индексы не требуют сканирования в обратном порядке, что значительно увеличивает эффективность работы с убывающими значениями; -  Реализована (https://mysqlserverteam.com/mysql-8-0-grouping-function/) функция GROUPING(), которая позволяет отделить NULL-значения, полученные в результате агрегирования строк при группировке GROUP BY с использованием таких расширений, как ROLLUP, от  NULL-значений в обычных сгруппированных строках; -  Добавлены новые подсказки для управления поведением оптимизатора (задаются внутри комментария /*+ */, указываемого сразу после ключевых слов  SELECT, INSERT, REPLACE, UPDATE  и DELETE): INDEX_MERGE и NO_INDEX_MERGE для управления поведением слияния индексов для отдельных запросов,  JOIN_FIXED_ORDER, JOIN_ORDER, JOIN_PREFIX и JOIN_SUFFIX для управления порядком обработки таблиц при выполнении слияния, SET_VAR для установки системной переменной в контексте текущего выражения; -  Добавлены новые функции для манипуляции данными в формате JSON: -  Расширен синтаксис для определения диапазонов значений в JSON, например "SELECT JSON_EXTRACT('[1, 2, 3, 4, 5]', '$[1 to 3]');". -  Добавлена поддержка табличных функций, позволяющих использовать SQL для данных JSON (при помощи функции JSON_TABLE() создаётся реляционного представление данных JSON). -  Добавлены агрегатные функции JSON_ARRAYAGG() для генерации массивов JSON и JSON_OBJECTAGG() для генерации объектов JSON. -  Добавлены функции слияния  JSON_MERGE_PATCH() и  JSON_MERGE_PRESERVE(). Добавлена функция  JSON_PRETTY() для приведения блоков JSON к читаемому виду; -  Добавлена функция JSON_STORAGE_SIZE() для вычисления размера, который занимает объект JSON; -  От 1.2 до 18 раз увеличена производительность сортировки и группировки значений JSON; -  Добавлена поддержка пространственных типов данных, индексов и функций, позволяющих работать с географическими координатами и картографическими данными; -  По умолчанию задействована кодировка UTF8MB4 (https://dev.mysql.com/doc/refman/5.5/en/charset-unicode-utf8...) (ранее применялась кодировка latin1) и поддержка свойства локали "Collation", позволяющего задавать правила сортировки и методы сопоставления с учётом смысла символов. По сравнению с версией MySQL 5.7 существенно (до 20 раз) увеличена производительность сортировки данных в кодировке UTF8MB4; -  Transactional Data Dictionary (https://dev.mysql.com/doc/refman/8.0/en/data-dictionary.html) - новый механизм хранения системных данных, поддерживающий транзакции и реализованный в видео набора SQL-таблиц, хранимых  отдельном табличном пространстве  InnoDB; -  Новая система ролей (https://dev.mysql.com/doc/refman/8.0/en/roles.html) (именованных коллекций привилегий), позволяющая делегировать и блокировать полномочия для групп пользователей; -  Задействован по умолчанию плагин аутентификации caching_sha2_password (https://dev.mysql.com/doc/refman/8.0/en/caching-sha2-pluggab...), использующий  SHA-256 для хэширования паролей, но по сравнению с плагином sha256_password  обеспечивающий более высокую производительность за счёт использования кэширования; -  В качестве библиотеки с реализацией TLS/SSL по умолчанию задействован OpenSSL;-  Проведены различные оптимизации производительности, например, в тесте upto достигнуто почти двухкратное ускорение и производительность на уровне 1.8 млн запросов в секунду. Скорость запросов к таблицам  Performance Schema возросла до 30 раз, а к таблицам Information Schema до 100 раз. URL: https://mysqlserverteam.com/whats-new-in-mysql-8-0-generally.../ Новость: https://www.opennet.dev/opennews/art.shtml?num=48466
Ответить | Правка | Cообщить модератору

Сообщения по теме

[Сортировка по времени | RSS]

1. "Стабильный релиз СУБД MySQL 8.0"	+4 +/–
Сообщение от Аноним (-), 19-Апр-18, 23:30
Спасибо, но уже есть PostgreSQL и MariaDB.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	2. "Стабильный релиз СУБД MySQL 8.0"	+3 +/–
	Сообщение от KonstantinB (ok), 19-Апр-18, 23:35
	Это лучше, чем MariaDB, они выпилили myisam насовсем, в том числе из служебных таблиц.
	Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

	3. "Стабильный релиз СУБД MySQL 8.0"	+/–
	Сообщение от Имя (?), 19-Апр-18, 23:49
	Aria?
	Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

	4. "Стабильный релиз СУБД MySQL 8.0"	–2 +/–
	Сообщение от KonstantinB (ok), 20-Апр-18, 00:09
	Фигария, попробуй сменить тип таблиц в базе mysql.
	Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору

	6. "Стабильный релиз СУБД MySQL 8.0"	–1 +/–
	Сообщение от KonstantinB (ok), 20-Апр-18, 00:12
	https://dev.mysql.com/doc/refman/8.0/en/data-dictionary.html
	Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору

	5. "Стабильный релиз СУБД MySQL 8.0"	+/–
	Сообщение от Gemorroj (ok), 20-Апр-18, 00:11
	вот тоже уже думаю обратно на ванильный mysql с марии переезжать. честный json, sys схема... в то время как мария начала ломать совместимость с оригинальным mysql (тот же json), что сильно снижает ее привлекательность.
	Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

	7. "Стабильный релиз СУБД MySQL 8.0"	+2 +/–
	Сообщение от KonstantinB (ok), 20-Апр-18, 00:15
	Еще CTE и window-функции завезли. Я с бетой игрался, отлично, уже прям настоящая РСУБД, скоро постгрес догонит.
	Ответить | Правка | ^ к родителю #5 | Наверх | Cообщить модератору

	46. "Стабильный релиз СУБД MySQL 8.0"	–1 +/–
	Сообщение от Gemorroj (ok), 20-Апр-18, 11:29
	я пока заткнулся с https://dev.mysql.com/doc/refman/8.0/en/mysql-secure-install... # mysql_secure_installation Securing the MySQL server deployment. Connecting to MySQL using a blank password. Segmentation fault
	Ответить | Правка | ^ к родителю #7 | Наверх | Cообщить модератору

	70. "Стабильный релиз СУБД MySQL 8.0"	+1 +/–
	Сообщение от Аноним (-), 21-Апр-18, 09:30
	> Segmentation fault Обычно перестаёт быть страшно к N.X.20-26, а в важных местах к N.X.40 Но ходят слухи, что минорная нумерация версий тоже поменяется/поменялась.
	Ответить | Правка | ^ к родителю #46 | Наверх | Cообщить модератору

	15. "Стабильный релиз СУБД MySQL 8.0"	+/–
	Сообщение от Монти Пайтон (?), 20-Апр-18, 01:29
	Percona умеет половину из Maria и Mysql 8.0
	Ответить | Правка | ^ к родителю #5 | Наверх | Cообщить модератору

	20. "Стабильный релиз СУБД MySQL 8.0"	+2 +/–
	Сообщение от KonstantinB (ok), 20-Апр-18, 06:00
	> Percona умеет половину из Maria и Mysql 8.0 Transactional data dictionary не умеют, это самое главное. Тут я восхищаюсь объемом проделанной работы. Системные словари относятся к самому древнему окаменевшему коду, который Монти писал на коленке в далеких девяностых, и myisam был прибит гвоздями наглухо кондовым хардкодом везде, где можно и нельзя.
	Ответить | Правка | ^ к родителю #15 | Наверх | Cообщить модератору

	56. "Стабильный релиз СУБД MySQL 8.0"	+/–
	Сообщение от Аноним (-), 20-Апр-18, 17:50
	myisam гогно, тут я с вами согласен на все 100%
	Ответить | Правка | ^ к родителю #20 | Наверх | Cообщить модератору

	69. "Стабильный релиз СУБД MySQL 8.0"	+/–
	Сообщение от Аноним (-), 21-Апр-18, 09:27
	> Percona умеет половину из Maria и Mysql 8.0 Percona не пилит новые божественные фичи. Percona Server это ванильный оракловый MySQL + набор фишек повышающих производительность (чаще меньше чем следующий мажорный релиз от Oracle) + удобства диагностики (больше инфы в slowlog, userstats) + энтерпрайз фишки под GPL вроде PAM audit_plugin. MariaDB пилят свои фишки отдельно, на своём форке mysql 5.5, без оглядки что это надо/можно будет объединить с Oracle MySQL. Так что Percona Server 8.0 выйдет через пару месяцев и будет уметь то же что и MySQL 8.0, а фишки из MariaDB доступны только плагинные. Никакой магии нет, все три компании занимаются разным в плане разработки.
	Ответить | Правка | ^ к родителю #15 | Наверх | Cообщить модератору

	82. "Стабильный релиз СУБД MySQL 8.0"	+/–
	Сообщение от KonstantinB (ok), 23-Апр-18, 21:01
	А вот так они могут? :-) https://www.reddit.com/r/brainfuck/comments/83cw7l/i_impleme.../ C рекурсивным CTE, кстати, MySQL-евский диалект SQL стал тьюринг-полным языком. :-)
	Ответить | Правка | ^ к родителю #15 | Наверх | Cообщить модератору

	40. "Стабильный релиз СУБД MySQL 8.0"	+/–
	Сообщение от feudor (ok), 20-Апр-18, 11:09
	мария начала ломать совместимость с оригинальным mysql хорошая шутка.
	Ответить | Правка | ^ к родителю #5 | Наверх | Cообщить модератору

	45. "Стабильный релиз СУБД MySQL 8.0"	–2 +/–
	Сообщение от Gemorroj (ok), 20-Апр-18, 11:28
	ну поработай с json, найди там хоть какой-то сходство.
	Ответить | Правка | ^ к родителю #40 | Наверх | Cообщить модератору

	52. "Стабильный релиз СУБД MySQL 8.0"	+/–
	Сообщение от feudor (ok), 20-Апр-18, 13:21
	я про то что оригинальный MySQL это и есть мария.
	Ответить | Правка | ^ к родителю #45 | Наверх | Cообщить модератору

	61. "Стабильный релиз СУБД MySQL 8.0"	+/–
	Сообщение от Ilya Indigo (ok), 21-Апр-18, 03:56
	https://jira.mariadb.org/browse/MDEV-13594 Ответ на мой комментарий меня просто поразил. Я после того подумал про миграцию на PostgreSQL.
	Ответить | Правка | ^ к родителю #5 | Наверх | Cообщить модератору

	8. "Стабильный релиз СУБД MySQL 8.0"	–8 +/–
	Сообщение от IRASoldier (?), 20-Апр-18, 00:17
	Postgre пока не нyжен - детально так раъяснено почему - https://habrahabr.ru/company/devconf/blog/353682/
	Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

	9. "Стабильный релиз СУБД MySQL 8.0"	+1 +/–
	Сообщение от KonstantinB (ok), 20-Апр-18, 00:33
	Чтобы с озвученной Uber-ом проблемой столкнуться, нужен особый характер нагрузки - множество апдейтов в секунду, затрагивающих индекс. Для большинства проектов это не критично.
	Ответить | Правка | ^ к родителю #8 | Наверх | Cообщить модератору

	24. "Стабильный релиз СУБД MySQL 8.0"	–3 +/–
	Сообщение от Аноним (-), 20-Апр-18, 07:21
	Из статьи следует, что апдейты индексированнного поля и неиндексированного одинаково тяжеловесны в Постгри.   Использование СУБД файлового кеша ОСи убило ваапще. Подумывал опробывать Постги, но теперь обожду.
	Ответить | Правка | ^ к родителю #9 | Наверх | Cообщить модератору

	59. "Стабильный релиз СУБД MySQL 8.0"	+/–
	Сообщение от Аноним (-), 20-Апр-18, 20:23
	> Использование СУБД файлового кеша ОСи убило ваапще. И чем же?
	Ответить | Правка | ^ к родителю #24 | Наверх | Cообщить модератору

	71. "Стабильный релиз СУБД MySQL 8.0"	+/–
	Сообщение от Аноним (-), 21-Апр-18, 09:38
	>> Использование СУБД файлового кеша ОСи убило ваапще. > И чем же? Если горячая страничка (на чтение) вытеснится из кеша ОС, сразу пачка одновременных запросов может заблокироваться, за это время придёт ещё пачка запросов и база будет работать медленнее из-за скачка нагрузки (больше тредов/процессов - больше блокировок). Эту проблему можно убрать, если кешировать в shared memory сегменте базы, но без direct io одни и те же данные будут и в shared memory и в кеше ОС, а значит надо для одних и тех же данных закупать на 20-30% больше оперативной памяти если база не работает/не эфективно работает с direct io.
	Ответить | Правка | ^ к родителю #59 | Наверх | Cообщить модератору

	86. "Стабильный релиз СУБД MySQL 8.0"	+/–
	Сообщение от Аноним (-), 24-Апр-18, 22:31
	> одни и те же данные будут и в shared memory и в кеше ОС Как долго? Это не так просто оценить, у shared_buffers и у кеша ОС есть алгоритмы вытеснения не используемых данных, в конечном счёте в shared_buffers останутся горячие данные, а в кеше ОС — тёплые (другие), потому что данные находящиеся в shared_buffers не запрашиваются у ОС и вытесняются из кеша, не так ли?
	Ответить | Правка | ^ к родителю #71 | Наверх | Cообщить модератору

	62. "Стабильный релиз СУБД MySQL 8.0"	+1 +/–
	Сообщение от KonstantinB (ok), 21-Апр-18, 04:29
	То, что сейчас кажется дикостью, 20 лет назад было оптимальным решением. Хранилище постгреса проектировалось в те далекие времена, когда никаких O_DIRECT не было даже в планах. В условиях какого-нибудь ядра 1.4 или freebsd 3 это было наиболее эффективным решением. Оттуда же и пачки процессов и shared memory - никаких epoll-ов и прочих kevent тоже не было, с тредами все было печально. Но, надо заметить, все это и сейчас весьма неплохо работает.
	Ответить | Правка | ^ к родителю #24 | Наверх | Cообщить модератору

	78. "Стабильный релиз СУБД MySQL 8.0"	+/–
	Сообщение от нах (?), 22-Апр-18, 21:38
	> То, что сейчас кажется дикостью, 20 лет назад было оптимальным решением. и пока линуксеры не доломали совместимость с нормальными юниксами - вполне пристойно работает. родовая травма постгреза - его причудливейший формат storage, корнями уходящий в великую бесполезно-фичу time-travel (не работающую со времен postgresql95) с вечным vacuum ("мы его уже совсем-совсем deprecated, он ненужен-ненужен...а, нет, разумеется он будет и дальше вызываться из внутреннего планировщика в самые неподходящие моменты, мы не об этом") и вечным разрастанием индексов. Что новый-модный zheap решит эти проблемы не создав попутно все те же что у myisam и еще пачку уникальных - что-то вот не верится.
	Ответить | Правка | ^ к родителю #62 | Наверх | Cообщить модератору

	55. "Стабильный релиз СУБД MySQL 8.0"	+/–
	Сообщение от letsmac (ok), 20-Апр-18, 15:51
	Чтобы с этой проблемой столкнуться надо написать оптимизированную логику под MySQL, а потом перенести эту логику на Postgres. У которой свои оптимизации. >>Для большинства проектов это не критично. Postgres не любит апдейтов, как и любой версионник. Для кучи апдейтов лучше уж NoSQL использовать.
	Ответить | Правка | ^ к родителю #9 | Наверх | Cообщить модератору

	64. "Стабильный релиз СУБД MySQL 8.0"	+/–
	Сообщение от funny. falcon (?), 21-Апр-18, 08:23
	Извините, но Innodb тоже версионник. Однока он лучше сравляется спробоемой потому, что у него быстрее всего доступна именно последняя версия строки. В постгрессе же последняя версия строки чаще всего попадает в экзкьютор последней.
	Ответить | Правка | ^ к родителю #55 | Наверх | Cообщить модератору

	10. "Стабильный релиз СУБД MySQL 8.0"	–2 +/–
	Сообщение от Аноним (-), 20-Апр-18, 00:33
	Не нужен кому? PostgreSQL это из разряда MSSQL, продукции Oracle, Sybase. З.Ы. топить за MyISAM не смешно и не весело ни разу.
	Ответить | Правка | ^ к родителю #8 | Наверх | Cообщить модератору

	11. "Стабильный релиз СУБД MySQL 8.0"	+/–
	Сообщение от Аноним (-), 20-Апр-18, 00:40
	А чем myisam плох для определённых случаев? Вот есть десяток девелоперских баз. На myisam заливка дампа  на два с половиной гигабайта с прода занимает от силы 10 минут. На Inno/XtraDB - в лучшем случае час, и всякие игрища с параметрами в my.cnf и системной схеме не особо помогают.
	Ответить | Правка | ^ к родителю #10 | Наверх | Cообщить модератору

	12. "Стабильный релиз СУБД MySQL 8.0"	+1 +/–
	Сообщение от KonstantinB (ok), 20-Апр-18, 00:58
	Для девелоперской базы никто не мешает остановить mysqld и ручками скопировать innodb-файлы.
	Ответить | Правка | ^ к родителю #11 | Наверх | Cообщить модератору

	17. "Стабильный релиз СУБД MySQL 8.0"	+1 +/–
	Сообщение от angra (ok), 20-Апр-18, 02:52
	Потом попробовать стартануть мускул, почитать ругань, а если он таки стартанул, то попытаться найти таблицы и обнаружить их отсутствие. Повторить процесс такого горячего копирования несколько раз, до тех пор пока не придет осознание, что ты что-то делаешь неправильно. Потом пойти почитать про кучу дополнительных телодвижений и условий, необходимых для использования такого метода с innodb.
	Ответить | Правка | ^ к родителю #12 | Наверх | Cообщить модератору

	19. "Стабильный релиз СУБД MySQL 8.0"	+1 +/–
	Сообщение от KonstantinB (ok), 20-Апр-18, 05:54
	Ничего сложного, совсем. Во-первых, можно скопировать содержимое /var/lib/mysql вообще целиком Во-вторых, если хочется частично, https://dev.mysql.com/doc/refman/5.6/en/innodb-migration.html
	Ответить | Правка | ^ к родителю #17 | Наверх | Cообщить модератору

	27. "Стабильный релиз СУБД MySQL 8.0"	+/–
	Сообщение от angra (ok), 20-Апр-18, 07:50
	> Ничего сложного, совсем. Я не говорил, что сложно или невыполнимо. Но простое копирование как с MYISAM приведет к проблемам. > Во-первых, можно скопировать содержимое /var/lib/mysql вообще целиком Можно и не такие глупости сделать, но зачем? Задача то ведь несколько другая была. > Во-вторых, если хочется частично, https://dev.mysql.com/doc/refman/5.6/en/innodb-migration.html А ты прочитать содержимое своей ссылки пробовал? Вдруг окажется, что там ровно то, что я и говорил: "кучу дополнительных телодвижений и условий, необходимых для использования такого метода с innodb."
	Ответить | Правка | ^ к родителю #19 | Наверх | Cообщить модератору

	30. "Стабильный релиз СУБД MySQL 8.0"	+/–
	Сообщение от KonstantinB (ok), 20-Апр-18, 08:09
	Да ладно куча, элементарно все.
	Ответить | Правка | ^ к родителю #27 | Наверх | Cообщить модератору

	31. "Стабильный релиз СУБД MySQL 8.0"	+/–
	Сообщение от KonstantinB (ok), 20-Апр-18, 08:11
	> Задача то ведь несколько другая была Задача была импортировать данные на машину разработчика. Для этого можно и так сделать. А можно вообще сделать "грязный" rsync, после чего стопнуть слейв на минутку и сделать еще один.
	Ответить | Правка | ^ к родителю #27 | Наверх | Cообщить модератору

	72. "Стабильный релиз СУБД MySQL 8.0"	+/–
	Сообщение от Аноним (-), 21-Апр-18, 10:00
	>> Во-вторых, если хочется частично, https://dev.mysql.com/doc/refman/5.6/en/innodb-migration.html > А ты прочитать содержимое своей ссылки пробовал? Вдруг окажется, что там ровно > то, что я и говорил: "кучу дополнительных телодвижений и условий, необходимых > для использования такого метода с innodb." Нет утилиты официальной, чтобы бекапить всю базу и разворачивать её с помощью transportable tablespaces. Я делал такой набросок для бекапа: https://pastebin.com/9r6ftxRg для рестора надо дописывать: залить структуру: *.struct.sql сделать discard для tablespace всех останавливаемых  таблиц (или по regex отфильтрованных) сделать mv/cp/rsync ibd и cfg файлов сделать import Ну и переделать Process на Pool чтобы копировать/востанавливать параллельно.
	Ответить | Правка | ^ к родителю #27 | Наверх | Cообщить модератору

	22. "Стабильный релиз СУБД MySQL 8.0"	+/–
	Сообщение от Аноним (-), 20-Апр-18, 06:58
	Если останавливают процессы, то это не горячее а холодное копирование.
	Ответить | Правка | ^ к родителю #17 | Наверх | Cообщить модератору

	25. "Стабильный релиз СУБД MySQL 8.0"	+/–
	Сообщение от angra (ok), 20-Апр-18, 07:41
	Из контекста остановка продакшена не предусматривалась и про использование реплики не говорилось.
	Ответить | Правка | ^ к родителю #22 | Наверх | Cообщить модератору

	26. "Стабильный релиз СУБД MySQL 8.0"	+/–
	Сообщение от ыы (?), 20-Апр-18, 07:45
	> Из контекста остановка продакшена не предусматривалась и про использование реплики не говорилось. В общем вместо чтения документации - каждый на своей волне :)
	Ответить | Правка | ^ к родителю #25 | Наверх | Cообщить модератору

	28. "Стабильный релиз СУБД MySQL 8.0"	+1 +/–
	Сообщение от KonstantinB (ok), 20-Апр-18, 08:03
	Вообще-то там речь о девелоперских базах шла. И что это такой за продакшен без реплики или xtrabackup?
	Ответить | Правка | ^ к родителю #25 | Наверх | Cообщить модератору

	38. "Стабильный релиз СУБД MySQL 8.0"	+/–
	Сообщение от ыы (?), 20-Апр-18, 11:06
	> Вообще-то там речь о девелоперских базах шла. > И что это такой за продакшен без реплики или xtrabackup? там может быть все что угодно. например 386DX2... какой-то хостинг с 64 мегами озу и низвестно что еще. Потому что 2,5 гига он заливает час... У меня это происходит несколько быстрее: ./load_test.sh load innodb real    2m21.104s user    0m8.648s sys    0m1.101s load isam real    0m26.690s user    0m8.809s sys    0m1.233s ./dump_test.sh dump innodb real    0m11.196s user    0m9.231s sys    0m1.441s dump isam real    0m11.911s user    0m9.563s sys    0m1.435s
	Ответить | Правка | ^ к родителю #28 | Наверх | Cообщить модератору

	73. "Стабильный релиз СУБД MySQL 8.0"	+/–
	Сообщение от Аноним (-), 21-Апр-18, 10:09
	> там может быть все что угодно. например 386DX2... какой-то хостинг с 64 > мегами озу и низвестно что еще. Потому что 2,5 гига он > заливает час... > У меня это происходит несколько быстрее: даже с mysqldump+innodb есть фокусы/настройки, чтобы заливать дамп быстрее история о сокращение востановления бекапа с двух часов (дефолтовые настройки, hdd) до 15 минут (ssd, настройки, параллельная загрузка): https://www.percona.com/blog/2018/02/22/restore-mysql-logica.../ Ну и есть mydumper с которым тоже можно быстро бекапить/загружать.
	Ответить | Правка | ^ к родителю #38 | Наверх | Cообщить модератору

	84. "Стабильный релиз СУБД MySQL 8.0"	+/–
	Сообщение от angra (ok), 24-Апр-18, 04:55
	Да уж, заменить hdd на ssd тот еже фокус/настройка. Предлагаю не менее эффективные фокусы/настройки: добавить еще 64 гига памяти и заменить процессор на топовый.
	Ответить | Правка | ^ к родителю #73 | Наверх | Cообщить модератору

	83. "Стабильный релиз СУБД MySQL 8.0"	+/–
	Сообщение от angra (ok), 24-Апр-18, 04:52
	Заметь, что соотношение осталось прежним 1:6
	Ответить | Правка | ^ к родителю #38 | Наверх | Cообщить модератору

	53. "Стабильный релиз СУБД MySQL 8.0"	+/–
	Сообщение от Аноним (-), 20-Апр-18, 13:51
	Это была поправка на конкретное высказывание http://www.opennet.dev/openforum/vsluhforumID3/114115.html#12
	Ответить | Правка | ^ к родителю #25 | Наверх | Cообщить модератору

	39. "Стабильный релиз СУБД MySQL 8.0"	+/–
	Сообщение от Валик228 (?), 20-Апр-18, 11:07
	вам бы попробовать дампить базу с ключем --disable-keys
	Ответить | Правка | ^ к родителю #11 | Наверх | Cообщить модератору

	13. "Стабильный релиз СУБД MySQL 8.0"	–1 +/–
	Сообщение от Аноним (-), 20-Апр-18, 01:05
	Статья устаревшая из-за старой используемой версии у Убера. Хотя, конечно, никто не без проблем.
	Ответить | Правка | ^ к родителю #8 | Наверх | Cообщить модератору

	14. "Стабильный релиз СУБД MySQL 8.0"	+1 +/–
	Сообщение от KonstantinB (ok), 20-Апр-18, 01:09
	Да пофиг какая версия, основное там - это родовая проблема с организацией данных. Из-за нее, кстати, и нужен тяжелый VACUUM. Патчи в новых версиях только смягчают проблему, но не решают. Все остальные пункты - действительно мелкие придирки.
	Ответить | Правка | ^ к родителю #13 | Наверх | Cообщить модератору

	63. "Стабильный релиз СУБД MySQL 8.0"	+/–
	Сообщение от Ilya Indigo (ok), 21-Апр-18, 05:08
	> Postgre пока не нyжен - детально так раъяснено почему - https://habrahabr.ru/company/devconf/blog/353682/ Благодарю за ссылку! Зачитался и задумался аж на 2 часа.
	Ответить | Правка | ^ к родителю #8 | Наверх | Cообщить модератору

	81. "Стабильный релиз СУБД MySQL 8.0"	+/–
	Сообщение от fi (ok), 23-Апр-18, 14:30
	этот старый вброс давно разобран по косточкам — там в основном проблемы разраба, плюс ему очен хотелось MySQL
	Ответить | Правка | ^ к родителю #8 | Наверх | Cообщить модератору

	16. "Стабильный релиз СУБД MySQL 8.0"	–3 +/–
	Сообщение от rshadow (ok), 20-Апр-18, 01:37
	Постгря плохо работает с индексами. И разрабы абсолютно упираются от создания инструмента ручного управления ими. Так что директивы и невидимые индексы выглядят вкусно.
	Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

	33. "Стабильный релиз СУБД MySQL 8.0"	+1 +/–
	Сообщение от Кабан ЛяЛя (?), 20-Апр-18, 09:11
	Это где она плохо работает? Хоть один пример... За ручное управление индексами "по шапке"!
	Ответить | Правка | ^ к родителю #16 | Наверх | Cообщить модератору

	41. "Стабильный релиз СУБД MySQL 8.0"	+/–
	Сообщение от Аноним (-), 20-Апр-18, 11:12
	Тут не про индексы наверное имелось ввиду а про оптимизатор.
	Ответить | Правка | ^ к родителю #33 | Наверх | Cообщить модератору

	50. "Стабильный релиз СУБД MySQL 8.0"	+/–
	Сообщение от rshadow (ok), 20-Апр-18, 13:16
	Ну да. Начиная с COUNT(*) который полным сканированием определяется, заканчивая явными глюками оптимизатора, которые может когда нибудь и починят.
	Ответить | Правка | ^ к родителю #41 | Наверх | Cообщить модератору

	74. "Стабильный релиз СУБД MySQL 8.0"	+/–
	Сообщение от Аноним (-), 21-Апр-18, 10:28
	> Ну да. Начиная с COUNT(*) который полным сканированием определяется, В 5.7, кстати select count(*) чуток ускорили. InnoDB: SELECT COUNT(*) FROM t statements now invoke a single handler call to the storage engine to scan the clustered index and return the row count to the Optimizer. Previously, a row count was typically performed by traversing a smaller secondary index and invoking a handler call for each record. A single handler call to the storage engine to count rows in the clustered index improves SELECT COUNT(*) FROM t performance in most cases. For more information, see Limits on InnoDB Tables. Сделать без скана довольно сомнительно: каким образом правильное количество должно возвращаться для кучи параллельных транзакций? > заканчивая явными глюками оптимизатора, которые может когда нибудь и починят. большая часть проблем связана со статистикой. При неравномерном распределении значений статистика указывает оптимизатору пальцем в небо. В 8.0 добавили гистограммы в статистику: https://dev.mysql.com/doc/refman/8.0/en/optimizer-statistics... так что надо смотреть как оно на реальных запросах и базах будет помогать.
	Ответить | Правка | ^ к родителю #50 | Наверх | Cообщить модератору

	51. "Стабильный релиз СУБД MySQL 8.0"	+/–
	Сообщение от rshadow (ok), 20-Апр-18, 13:21
	Совершенно с вами согласен. Только для сферического мира где планировщик не глючит, ALTER TABLE...NOT NULL всегда делается мгновенно на боевой бд, и вообще есть беспростойный апгрейд версии через репликацию. Очень хочется просто вводить команды, а оно само оптимизировалось, расползалось по кластеру, делалось мгновенно и без глюков.
	Ответить | Правка | ^ к родителю #33 | Наверх | Cообщить модератору

23. "Стабильный релиз СУБД MySQL 8.0"	–1 +/–
Сообщение от Анонимъ (?), 20-Апр-18, 07:21
Ура?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	29. "Стабильный релиз СУБД MySQL 8.0"	+1 +/–
	Сообщение от Николай (??), 20-Апр-18, 08:05
	> Ура? Да
	Ответить | Правка | ^ к родителю #23 | Наверх | Cообщить модератору

32. "Стабильный релиз СУБД MySQL 8.0"	+/–
Сообщение от Аноним (-), 20-Апр-18, 09:07
Про партицирование ничего не сказали. Его поправили? Можно теперь совмещать в таблице партиции разных движков?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	34. "Стабильный релиз СУБД MySQL 8.0"	–1 +/–
	Сообщение от Ануним (?), 20-Апр-18, 10:03
	О, помню этот баг. Помнится, из-за него я рабочий проект потребовал на MSSQL перевести.
	Ответить | Правка | ^ к родителю #32 | Наверх | Cообщить модератору

	48. "Стабильный релиз СУБД MySQL 8.0"	+/–
	Сообщение от Аноним (-), 20-Апр-18, 12:07
	А мы накостыляли кучу запросов, отображений, триггеров, чтобы работать с разными устройствами хранения данных в рамках одной таблицы. Хотя фактически это были разные таблицы. В итоге забили, перевели на SSD, которые мрут как мухи, но обеспечивают стабильную поддержку ПО. Не понятно, зачем вводить в протокол функционал, который они и не собирались поддерживать. Подразнить?...
	Ответить | Правка | ^ к родителю #34 | Наверх | Cообщить модератору

	66. "Стабильный релиз СУБД MySQL 8.0"	+/–
	Сообщение от Аноним (-), 21-Апр-18, 08:34
	> А мы накостыляли кучу запросов, отображений, триггеров, чтобы работать с разными устройствами > хранения данных в рамках одной таблицы. а DATA DIRECTORY не пробовали с партициями? https://dev.mysql.com/doc/refman/5.7/en/partitioning-subpart...
	Ответить | Правка | ^ к родителю #48 | Наверх | Cообщить модератору

	65. "Стабильный релиз СУБД MySQL 8.0"	+/–
	Сообщение от Аноним (-), 21-Апр-18, 08:29
	Наоборот выпилили эту возможность: https://dev.mysql.com/doc/mysql-partitioning-excerpt/8.0/en/... In MySQL 8.0, partitioning support is provided by the InnoDB storage engine. (The NDB storage engine used by MySQL Cluster also provides partitioning support, but NDB is not included in MySQL 8.0.) MySQL 8.0 does not currently support partitioning of tables using any storage engine other than InnoDB, such as MyISAM. An attempt to create a partitioned tables using a storage engine that does not supply native partitioning support fails with ER_CHECK_NOT_IMPLEMENTED.
	Ответить | Правка | ^ к родителю #32 | Наверх | Cообщить модератору

35. "Стабильный релиз СУБД MySQL 8.0"	+/–
Сообщение от luserz (?), 20-Апр-18, 10:36
параллельность добавили выполнения запросов? или всё так же в одну каску молотит каждый запрос?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

36. "Стабильный релиз СУБД MySQL 8.0"	+/–
Сообщение от анонимус (??), 20-Апр-18, 10:52
А когда MySQL начнет поддерживать транзакции при изменении структуры таблиц? PostgreSQL это умеет. Я не говорю уже про Oracle/MsSQL. Почему я не могу аггрегировать данные в колонку при группировке с сохранением типов? GROUP_CONCAT возвращает строку. Когда функция GROUP_CONCAT перестанет тихой сапой резать результирующую строку, в случае если строка превышает значение установленное в group_concat_max_len? Такого поведения там полно. И пока его не пофиксят MySQL так и останется недоСУБД.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	37. "Стабильный релиз СУБД MySQL 8.0"	+2 +/–
	Сообщение от Фуррь (ok), 20-Апр-18, 10:59
	>PostgreSQL это умеет. Я не говорю уже про Oracle/MsSQL. Обычно такие претензии возникают из-за непонимания того, что MySQL - это маленькая быстрая пони, и её нельзя грузить, как ломовую лошадь.
	Ответить | Правка | ^ к родителю #36 | Наверх | Cообщить модератору

	76. "Стабильный релиз СУБД MySQL 8.0"	+/–
	Сообщение от Адноним (?), 22-Апр-18, 14:34
	Маленькая пони полная Нонна из сомнительных решений и память она жрет в разы больше pgsql
	Ответить | Правка | ^ к родителю #37 | Наверх | Cообщить модератору

	42. "Стабильный релиз СУБД MySQL 8.0"	+/–
	Сообщение от Аноним (-), 20-Апр-18, 11:16
	> А когда MySQL начнет поддерживать транзакции при изменении структуры таблиц? PostgreSQL > это умеет. Я не говорю уже про Oracle/MsSQL. > Почему я не могу аггрегировать данные в колонку при группировке с сохранением > типов? GROUP_CONCAT возвращает строку. > Когда функция GROUP_CONCAT перестанет тихой сапой резать результирующую строку, в случае > если строка превышает значение установленное в group_concat_max_len? > Такого поведения там полно. И пока его не пофиксят MySQL так и > останется недоСУБД. А когда MySQL начнет поддерживать транзакции при изменении структуры таблиц? ... Я не говорю уже про Oracle. Разъясните пожалуйста что вы имеете ввиду, в Oracle DDL "атомарны" и "монопольно блокируют объект", что приводит к забавному поведению в некоторых среда ( PL/Sql Developer ) когда какой-нибудь truncate(не говоря уже о Alter table ) в одном окне а update(большая длинная процедура без commit) в другом приводит к подвисанию среды из-за lock wait.
	Ответить | Правка | ^ к родителю #36 | Наверх | Cообщить модератору

	54. "Стабильный релиз СУБД MySQL 8.0"	+/–
	Сообщение от KonstantinB (ok), 20-Апр-18, 15:05
	> А когда MySQL начнет поддерживать транзакции при изменении структуры таблиц? Транзакционные системные словари и atomic DDL в 8.0 сделали, так что скоро. Вроде уже ничто не мешает.
	Ответить | Правка | ^ к родителю #42 | Наверх | Cообщить модератору

	43. "Стабильный релиз СУБД MySQL 8.0"	+/–
	Сообщение от Аноним (-), 20-Апр-18, 11:18
	> Такого поведения там полно. И пока его не пофиксят MySQL так и > останется недоСУБД. Так она по определению теперь такая, а так-же тестовый полигон и обучалка для будущего использования промышленной БД от oracle.
	Ответить | Правка | ^ к родителю #36 | Наверх | Cообщить модератору

	44. "Стабильный релиз СУБД MySQL 8.0"	+1 +/–
	Сообщение от Gemorroj (ok), 20-Апр-18, 11:24
	по 1 пункту - https://dev.mysql.com/doc/refman/8.0/en/data-dictionary.html для этого и делалось.
	Ответить | Правка | ^ к родителю #36 | Наверх | Cообщить модератору

47. "Стабильный релиз СУБД MySQL 8.0"	+1 +/–
Сообщение от rvs2016 (ok), 20-Апр-18, 11:45
> Версия 8.0 обусловлена сменой нумерации версий, > релиз выпущен следом за 5.7 вместо версии 5.8. Не понял прикола. Почему в смене версий с 5.7 на сразу 8.0 упор делается на то, что не было промежуточных версий с непонятными номерами типа 5.8 вместо указания на отсутствие более логичных номеров типа 6.0 да 7.0? ps: С версиями типа 6.* вроде прикол много лет назад ходил такой: начали делать шестые версии, а потом забросили и откатились обратно на пятые. А с седьмыми номерами прикол какой, в чём?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	57. "Стабильный релиз СУБД MySQL 8.0"	+/–
	Сообщение от Аноним (-), 20-Апр-18, 19:05
	Тут как с джавой логика, минорная циферка переехала в мажорную, потому что по факту 5.х это давно уже не минорные релизы.
	Ответить | Правка | ^ к родителю #47 | Наверх | Cообщить модератору

	58. "Стабильный релиз СУБД MySQL 8.0"	+2 +/–
	Сообщение от Аноним (-), 20-Апр-18, 19:07
	Да и Марию догонять надо :)
	Ответить | Правка | ^ к родителю #57 | Наверх | Cообщить модератору

49. "Стабильный релиз СУБД MySQL 8.0"	+/–
Сообщение от Аноним (-), 20-Апр-18, 12:48
Чего-то я не понял блокировка строк для обновления дальнейшего в таблице то появилась в транзакции уже? SELECT ... FOR UPDATE?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	67. "Стабильный релиз СУБД MySQL 8.0"	+/–
	Сообщение от Аноним (-), 21-Апр-18, 08:53
	> Чего-то я не понял блокировка строк для обновления дальнейшего в таблице то > появилась в транзакции уже? SELECT ... FOR UPDATE? SELECT FOR UPDATE был уже в 4.0, 2002 год, почти 16 лет назад. В 8.0 добавили возможность при использовании select for update либо выдать ошибку как только натолкнёмся на строчку заблокированную другой транзакцией NOWAIT (модифицированную или заблокированную S F U) либо молча пропускать строчки заблокированные другими транзакциями SKIP LOCKED. Сходу что приходит в голову, такие фишки позволяют делать очереди с несколькими обработчиками на кроне/event scheduler.
	Ответить | Правка | ^ к родителю #49 | Наверх | Cообщить модератору

60. "Стабильный релиз СУБД MySQL 8.0"	+2 +/–
Сообщение от Vitaliy Blats (?), 20-Апр-18, 20:35
Лучше бы не хренотень всякую придумывали, а сделали то, о чем ноют в интернетике с момента создания InnoDB - вменяемого рекавери. Которое именно срекаверит, максимум проигнорирует транзакции с ошибками и восстановит БД, а не высрет в лог кучу непонятной срани, а при попытке восстановить скажет "Ололо Got error: 1146: Table ‘database.table’ doesn’t exist when using бла бла бла"
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	68. "Стабильный релиз СУБД MySQL 8.0"	+/–
	Сообщение от Аноним (-), 21-Апр-18, 09:07
	> Лучше бы не хренотень всякую придумывали, а сделали то, о чем ноют > в интернетике с момента создания InnoDB - вменяемого рекавери. Которое именно > срекаверит, максимум проигнорирует транзакции с ошибками и восстановит БД, а не > высрет в лог кучу непонятной срани, а при попытке восстановить скажет > "Ололо Got error: 1146: Table ‘database.table’ doesn’t exist when using > бла бла бла" InnoDB модифицирует данные по месту, Если лог транзакций физически повреждён, то на диске могут быть страницы которые ссылаются вникуда (потому что это более свежая версия страницы) и невозможно построить валидное B-tree. Если лог транзакций не применён (innodb_force_recovery) или если просто есть повреждённые таблички то можно пытаться селектами достать данные. Если повреждения небольшие то некоторые ошибки могут быть проигнорированы https://www.percona.com/doc/percona-server/LATEST/reliabilit... Поэтому для таких случаев Алексей Кузьминский сделал свой innodb data recovery tool, который потом форкнул (после ухода из Percona) под названием undrop for innodb. Эта тулза сканирует ibd файл (или  даже блочное устройство если файлы были удалены с файловой системы) и ищет строчки по маске (которая делается из словаря innodb или frm файла). Движки типа дефолтного в postgresql или rocksdb устроены иначе и там можно попытаться проигнорировать ошибки WAL или применить его частично, а т.к. самые последние записи относятся именно к wal, то больше шансов выжить после повреждённых дисков, багов в ядре, багованных кешей на сторадже. В zheap https://www.opennet.dev/opennews/art.shtml?num=48214 будут те же самые проблемы с аварийным востановлением.
	Ответить | Правка | ^ к родителю #60 | Наверх | Cообщить модератору

	77. "Стабильный релиз СУБД MySQL 8.0"	+/–
	Сообщение от нах (?), 22-Апр-18, 18:16
	> Если лог транзакций физически повреждён, то на диске могут быть страницы которые ссылаются > вникуда (потому что это более свежая версия страницы) откатиться на несвежую или уж чорт с ним, потерять содержимое страницы целиком но сохранить остальные данные - не вариант?
	Ответить | Правка | ^ к родителю #68 | Наверх | Cообщить модератору

	79. "Стабильный релиз СУБД MySQL 8.0"	+/–
	Сообщение от Аноним (-), 22-Апр-18, 21:49
	> откатиться на несвежую или уж чорт с ним, потерять содержимое страницы целиком но сохранить остальные данные - не вариант? В каждой странице содержится ссылка на следующую и предыдущую. Если мы сделали сплит (одну страницу поменяли по месту и уже потеряли ссылку на старую следующую), а новую страницу потеряли при записи на диск, то всё пропало - потеряли связь со всеми последующими страницами. У innodb нет версий страниц, страницы меняются по месту. Есть версии строк - (старые строчки пишутся в undo segment), но это не поможет если вместо следующей странички указатель ведёт на мусор. Так что получается или втупую парсить, или пытаться по кускам делать select .. where из-под force recovery. Ну и если словарь повреждён то пытаться делать ibdconnect. Фатальный недостаток парсинга - все данные в csv виде на выходе и для терабайтной базы это всё надо ещё пару недель грузить. Потенциально можно сделать поиск "потерянных деревьев" страниц, но будут левые данные и несогласованные данные в табличках и совершенно не ясно что делать, если у страницы неверная контрольная сумма, так что лучше делать бекапы и point-in-time с помощью binary log.
	Ответить | Правка | ^ к родителю #77 | Наверх | Cообщить модератору

	80. "Стабильный релиз СУБД MySQL 8.0"	+/–
	Сообщение от нах (?), 23-Апр-18, 01:12
	ненене, фатальная проблема с парсингом непойми-чего в том, что мы получим не просто csv, а csv с не факт что нашими данными, а не похожим на них мусором с диска. то о чем я спрашивал - это как потерять часть данных (часто это можно себе позволить) но восстановить функционал системы. (то есть не force recovery, а нормальный режим работы, если приложение обломится о неконсистентность связанных таблиц или просто select вернет пустое место - это уже можно как-то переварить самим приложением) Но, видимо, в борьбе за эффективность переэкономили - в результате рухнувшая innodb, получается, вовсе не подлежит оживлению, только выковыривать тем или иным способом данные и пересоздавать ее с нуля (привет от оракла с его ora006). binary лог к сожалению не панацея - он-то может и быстро накатиться, да вот восстановление самой крупной базы займет неприлично много времени.
	Ответить | Правка | ^ к родителю #79 | Наверх | Cообщить модератору

87. "Стабильный релиз СУБД MySQL 8.0"	+/–
Сообщение от Alex (??), 04-Дек-18, 23:45
Мда.. вышел порт 8.0.12_1, затем 8.0.12_2 и не собирается.. откатывать обратно на 5.7... mysql80-server-8.0.12_2 is vulnerable: MySQL -- multiple vulnerabilities CVE: CVE-2018-3286 CVE: CVE-2018-3283 CVE: CVE-2018-3284 CVE: CVE-2018-3282 CVE: CVE-2018-3279 CVE: CVE-2018-3278 CVE: CVE-2018-3161 CVE: CVE-2018-3186 CVE: CVE-2018-3280 CVE: CVE-2018-3212 CVE: CVE-2018-3170 CVE: CVE-2018-3200 CVE: CVE-2018-3173 CVE: CVE-2018-3162 CVE: CVE-2018-3277 CVE: CVE-2018-3171 CVE: CVE-2018-3174 CVE: CVE-2018-3187 CVE: CVE-2018-3247 CVE: CVE-2018-3195 CVE: CVE-2018-3185 CVE: CVE-2018-3144 CVE: CVE-2018-3145 CVE: CVE-2018-3133 CVE: CVE-2018-3203 CVE: CVE-2018-3137 CVE: CVE-2018-3182 CVE: CVE-2018-3251 CVE: CVE-2018-3156 CVE: CVE-2018-3143 CVE: CVE-2018-3155 CVE: CVE-2016-9843 WWW: https://vuxml.FreeBSD.org/freebsd/ec5072b0-d43a-11e8-a6d2-b4...
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема