The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]



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

"Стабильный релиз СУБД 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 Blatsemail (?), 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"  +/
Сообщение от Alexemail (??), 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 | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру