The OpenNET Project / Index page

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

19.04.2018 23:25  Стабильный релиз СУБД MySQL 8.0

После двух с половиной лет разработки компания Oracle представила первый стабильный релиз СУБД MySQL 8.0. Версия 8.0 обусловлена сменой нумерации версий, релиз выпущен следом за 5.7 вместо версии 5.8. Сборки MySQL Community Server 8 сформированы для всех основных дистрибутивов Linux, FreeBSD, macOS и Windows.

Ключевые улучшения MySQL 8.0:

  • Добавлены оконные функции (window-функции или аналитические функции), позволяющие для каждой строки запроса выполнить вычисления, используя строки, связанные с текущей строкой. В отличие от агрегатных функций над сгруппированными строками, которые свёртывают сгруппированный набор строк в одну строку, оконные функции производят агрегирование для каждой строки в результирующем наборе. Реализованы как специальные оконные функции RANK, LAG, ROW_NUMBER, FIRST_VALUE, LEAD, LAG и NTILE, так и возможность применение некоторых агрегатных функций в форме оконных (например, COUNT, SUM, AVG, MIN, MAX);
  • Поддержка рекурсивных и не рекурсивных обобщённых табличных выражений (Common Table Expression), позволяющих использовать временные именованные результирующие наборы, задаваемые при помощи оператора WITH;
  • В InnoDB добавлена поддержка опций NOWAIT и SKIP LOCKED, которые можно использовать для управления поведением при наличии блокировок в момент выполнения выражений "SELECT ... FOR SHARE" и "SELECT ... FOR UPDATE". При указании NOWAIT управление будет возвращено сразу с выводом ошибки, если запрошенная строка заблокирована другой транзакцией, а при "SKIP LOCKED" заблокированные строки будут исключены из результирующего набора;
  • Поддержка невидимых индексов (Invisible Indexes), которые никогда не используются оптимизатором. Управление видимостью индекса производится при помощи ключевых слов VISIBLE и INVISIBLE. Обычный видимый индекс может быть превращён в невидимый и наоборот. Невидимые индексы можно использовать для тестирования влияния того или иного индекса на производительность, без физического удаления данного индекса (индекс можно перевести в режим невидимого, изучить изменение производительности и вернуть обратно);
  • Поддержка нисходящих индексов (descending indexes), позволяющих использовать оператор "DESC" при определении индекса для сохранения значений ключей в порядке убывания. В работе подобные индексы не требуют сканирования в обратном порядке, что значительно увеличивает эффективность работы с убывающими значениями;
  • Реализована функция 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;
  • Добавлен режим работы в качестве хранилища документов (Document Store), к которому можно обращаться с использованием методов NoSQL (коллекции JSON без предварительно определяемой схемы хранения). Функциональность реализована при помощи плагина mysqlxplugin;
  • Добавлена поддержка пространственных типов данных, индексов и функций, позволяющих работать с географическими координатами и картографическими данными;
  • По умолчанию задействована кодировка UTF8MB4 (ранее применялась кодировка latin1) и поддержка свойства локали "Collation", позволяющего задавать правила сортировки и методы сопоставления с учётом смысла символов. По сравнению с версией MySQL 5.7 существенно (до 20 раз) увеличена производительность сортировки данных в кодировке UTF8MB4;
  • Добавлены новые функции для использования регулярных выражений REGEXP_INSTR(), REGEXP_LIKE(), REGEXP_SUBSTR() и долгожданная функция замены при помощи регулярных выражений REGEXP_REPLACE(). Кроме того, в регулярных выражениях реализована корректная работа с многобайтовыми Unicode-символами;
  • Transactional Data Dictionary - новый механизм хранения системных данных, поддерживающий транзакции и реализованный в виде набора SQL-таблиц, хранимых в отдельном табличном пространстве InnoDB (хранение системных данных и метаданных в MyISAM прекращено);
  • Новая система ролей (именованных коллекций привилегий), позволяющая делегировать и блокировать полномочия для групп пользователей;
  • Добавлена возможность переименования столбцов (ALTER TABLE ... RENAME COLUMN old_name TO new_name);
  • Задействован по умолчанию плагин аутентификации caching_sha2_password, использующий SHA-256 для хэширования паролей, но по сравнению с плагином sha256_password обеспечивающий более высокую производительность за счёт использования кэширования;
  • Добавлена защита от атак по подбору паролей. В случае нескольких неудачных попыток аутентификации теперь между следующими попытками добавляется задержка;
  • Добавлена команда "SET PERSIST", позволяющая менять значения переменных конфигурации с сохранением их между перезапусками. Также добавлена команда RESTART, позволяющая удалённо перезапустить MySQL при наличии соответствующих полномочий;
  • В качестве библиотеки с реализацией TLS/SSL по умолчанию задействован OpenSSL;
  • Добавлена поддержка шифрования Undo- и Redo-логов;
  • Проведены различные оптимизации производительности, например, в тесте upto при 4 одновременно работающих клиентах достигнуто почти двухкратное ускорение - продемонстрирована производительность на уровне 1.8 млн запросов в секунду. Скорость запросов к таблицам Performance Schema возросла до 30 раз, а к таблицам Information Schema до 100 раз.

  1. Главная ссылка к новости (https://mysqlserverteam.com/wh...)
  2. OpenNews: Уязвимость в mysqldump, позволяющая выполнить код при восстановлении бэкапа
  3. OpenNews: Уязвимость в MySQL, позволяющая поднять свои привилегии
  4. OpenNews: В MySQL 8.0 отмечается закат хранилища MyISAM
  5. OpenNews: Критическая root-уязвимость в MySQL
  6. OpenNews: Компания Oracle анонсировала стабильный релиз MySQL 5.7
Лицензия: CC-BY
Тип: Интересно / Программы
Ключевые слова: mysql
При перепечатке указание ссылки на opennet.ru обязательно
Обсуждение Ajax/Линейный | Раскрыть все сообщения | RSS
 
  • 1.1, Аноним (-), 23:30, 19/04/2018 [ответить] [показать ветку] [···]    [к модератору]
  • +3 +/
    Спасибо, но уже есть PostgreSQL и MariaDB.
     
     
  • 2.2, KonstantinB (ok), 23:35, 19/04/2018 [^] [ответить]    [к модератору]
  • +3 +/
    Это лучше, чем MariaDB, они выпилили myisam насовсем, в том числе из служебных таблиц.
     
     
  • 3.3, Имя (?), 23:49, 19/04/2018 [^] [ответить]    [к модератору]
  • +/
    Aria?
     
     
  • 4.4, KonstantinB (ok), 00:09, 20/04/2018 [^] [ответить]    [к модератору]
  • –2 +/
    Фигария, попробуй сменить тип таблиц в базе mysql.
     
  • 4.6, KonstantinB (ok), 00:12, 20/04/2018 [^] [ответить]    [к модератору]
  • –1 +/
    https://dev.mysql.com/doc/refman/8.0/en/data-dictionary.html
     
  • 3.5, Gemorroj (ok), 00:11, 20/04/2018 [^] [ответить]     [к модератору]  
  • +/
    вот тоже уже думаю обратно на ванильный mysql с марии переезжать честный json, ... весь текст скрыт [показать]
     
     
  • 4.7, KonstantinB (ok), 00:15, 20/04/2018 [^] [ответить]    [к модератору]  
  • +2 +/
    Еще CTE и window-функции завезли.

    Я с бетой игрался, отлично, уже прям настоящая РСУБД, скоро постгрес догонит.

     
     
  • 5.46, Gemorroj (ok), 11:29, 20/04/2018 [^] [ответить]     [к модератору]  
  • –1 +/
    я пока заткнулся с https dev mysql com doc refman 8 0 en mysql-secure-installa... весь текст скрыт [показать]
     
     
  • 6.70, Аноним (-), 09:30, 21/04/2018 [^] [ответить]    [к модератору]  
  • +/
    > Segmentation fault

    Обычно перестаёт быть страшно к N.X.20-26, а в важных местах к N.X.40
    Но ходят слухи, что минорная нумерация версий тоже поменяется/поменялась.

     
  • 4.15, Монти Пайтон (?), 01:29, 20/04/2018 [^] [ответить]    [к модератору]  
  • +/
    Percona умеет половину из Maria и Mysql 8.0
     
     
  • 5.20, KonstantinB (ok), 06:00, 20/04/2018 [^] [ответить]     [к модератору]  
  • +2 +/
    Transactional data dictionary не умеют, это самое главное Тут я восхищаюсь объе... весь текст скрыт [показать]
     
     
  • 6.56, Аноним (-), 17:50, 20/04/2018 [^] [ответить]    [к модератору]  
  • +/
    myisam гогно, тут я с вами согласен на все 100%
     
  • 5.69, Аноним (-), 09:27, 21/04/2018 [^] [ответить]     [к модератору]  
  • +/
    Percona не пилит новые божественные фичи Percona Server это ванильный оракловый... весь текст скрыт [показать]
     
  • 5.82, KonstantinB (ok), 21:01, 23/04/2018 [^] [ответить]     [к модератору]  
  • +/
    А вот так они могут - https www reddit com r brainfuck comments 83cw7l i_im... весь текст скрыт [показать]
     
  • 4.40, feudor (ok), 11:09, 20/04/2018 [^] [ответить]    [к модератору]  
  • +/
    мария начала ломать совместимость с оригинальным mysql хорошая шутка.
     
     
  • 5.45, Gemorroj (ok), 11:28, 20/04/2018 [^] [ответить]    [к модератору]  
  • –2 +/
    ну поработай с json, найди там хоть какой-то сходство.
     
     
  • 6.52, feudor (ok), 13:21, 20/04/2018 [^] [ответить]    [к модератору]  
  • +/
    я про то что оригинальный MySQL это и есть мария.
     
  • 4.61, Ilya Indigo (ok), 03:56, 21/04/2018 [^] [ответить]    [к модератору]  
  • +/
    https://jira.mariadb.org/browse/MDEV-13594
    Ответ на мой комментарий меня просто поразил.
    Я после того подумал про миграцию на PostgreSQL.
     
  • 2.8, IRASoldier (?), 00:17, 20/04/2018 [^] [ответить]    [к модератору]  
  • –8 +/
    Postgre пока не нyжен - детально так раъяснено почему - https://habrahabr.ru/company/devconf/blog/353682/
     
     
  • 3.9, KonstantinB (ok), 00:33, 20/04/2018 [^] [ответить]    [к модератору]  
  • +1 +/
    Чтобы с озвученной Uber-ом проблемой столкнуться, нужен особый характер нагрузки - множество апдейтов в секунду, затрагивающих индекс. Для большинства проектов это не критично.
     
     
  • 4.24, Аноним (-), 07:21, 20/04/2018 [^] [ответить]     [к модератору]  
  • –3 +/
    Из статьи следует, что апдейты индексированнного поля и неиндексированного одина... весь текст скрыт [показать]
     
     
  • 5.59, Аноним (-), 20:23, 20/04/2018 [^] [ответить]    [к модератору]  
  • +/
    > Использование СУБД файлового кеша ОСи убило ваапще.

    И чем же?

     
     
  • 6.71, Аноним (-), 09:38, 21/04/2018 [^] [ответить]     [к модератору]  
  • +/
    Если горячая страничка на чтение вытеснится из кеша ОС, сразу пачка одновремен... весь текст скрыт [показать]
     
     
  • 7.86, Аноним (-), 22:31, 24/04/2018 [^] [ответить]     [к модератору]  
  • +/
    Как долго Это не так просто оценить, у shared_buffers и у кеша ОС есть алгоритм... весь текст скрыт [показать]
     
  • 5.62, KonstantinB (ok), 04:29, 21/04/2018 [^] [ответить]     [к модератору]  
  • +1 +/
    То, что сейчас кажется дикостью, 20 лет назад было оптимальным решением Хранили... весь текст скрыт [показать]
     
     
  • 6.78, нах (?), 21:38, 22/04/2018 [^] [ответить]     [к модератору]  
  • +/
    и пока линуксеры не доломали совместимость с нормальными юниксами - вполне прист... весь текст скрыт [показать]
     
  • 4.55, letsmac (ok), 15:51, 20/04/2018 [^] [ответить]     [к модератору]  
  • +/
    Чтобы с этой проблемой столкнуться надо написать оптимизированную логику под MyS... весь текст скрыт [показать]
     
     
  • 5.64, funny. falcon (?), 08:23, 21/04/2018 [^] [ответить]     [к модератору]  
  • +/
    Извините, но Innodb тоже версионник Однока он лучше сравляется спробоемой потом... весь текст скрыт [показать]
     
  • 3.10, Аноним (-), 00:33, 20/04/2018 [^] [ответить]    [к модератору]  
  • –2 +/
    Не нужен кому? PostgreSQL это из разряда MSSQL, продукции Oracle, Sybase.

    З.Ы. топить за MyISAM не смешно и не весело ни разу.

     
     
  • 4.11, Аноним (-), 00:40, 20/04/2018 [^] [ответить]     [к модератору]  
  • +/
    А чем myisam плох для определённых случаев Вот есть десяток девелоперских баз ... весь текст скрыт [показать]
     
     
  • 5.12, KonstantinB (ok), 00:58, 20/04/2018 [^] [ответить]    [к модератору]  
  • +1 +/
    Для девелоперской базы никто не мешает остановить mysqld и ручками скопировать innodb-файлы.
     
     
  • 6.17, angra (ok), 02:52, 20/04/2018 [^] [ответить]     [к модератору]  
  • +1 +/
    Потом попробовать стартануть мускул, почитать ругань, а если он таки стартанул, ... весь текст скрыт [показать]
     
     
  • 7.19, KonstantinB (ok), 05:54, 20/04/2018 [^] [ответить]    [к модератору]  
  • +1 +/
    Ничего сложного, совсем.
    Во-первых, можно скопировать содержимое /var/lib/mysql вообще целиком
    Во-вторых, если хочется частично, https://dev.mysql.com/doc/refman/5.6/en/innodb-migration.html
     
     
  • 8.27, angra (ok), 07:50, 20/04/2018 [^] [ответить]     [к модератору]  
  • +/
    Я не говорил, что сложно или невыполнимо Но простое копирование как с MYISAM пр... весь текст скрыт [показать]
     
     
  • 9.30, KonstantinB (ok), 08:09, 20/04/2018 [^] [ответить]    [к модератору]  
  • +/
    Да ладно куча, элементарно все.
     
  • 9.31, KonstantinB (ok), 08:11, 20/04/2018 [^] [ответить]     [к модератору]  
  • +/
    Задача была импортировать данные на машину разработчика Для этого можно и так с... весь текст скрыт [показать]
     
  • 9.72, Аноним (-), 10:00, 21/04/2018 [^] [ответить]     [к модератору]  
  • +/
    Нет утилиты официальной, чтобы бекапить всю базу и разворачивать её с помощью tr... весь текст скрыт [показать]
     
  • 7.22, Аноним (-), 06:58, 20/04/2018 [^] [ответить]    [к модератору]  
  • +/
    Если останавливают процессы, то это не горячее а холодное копирование.
     
     
  • 8.25, angra (ok), 07:41, 20/04/2018 [^] [ответить]    [к модератору]  
  • +/
    Из контекста остановка продакшена не предусматривалась и про использование реплики не говорилось.
     
     
  • 9.26, ыы (?), 07:45, 20/04/2018 [^] [ответить]    [к модератору]  
  • +/
    > Из контекста остановка продакшена не предусматривалась и про использование реплики не говорилось.

    В общем вместо чтения документации - каждый на своей волне :)

     
  • 9.28, KonstantinB (ok), 08:03, 20/04/2018 [^] [ответить]    [к модератору]  
  • +1 +/
    Вообще-то там речь о девелоперских базах шла.

    И что это такой за продакшен без реплики или xtrabackup?

     
     
  • 10.38, ыы (?), 11:06, 20/04/2018 [^] [ответить]     [к модератору]  
  • +/
    там может быть все что угодно например 386DX2 какой-то хостинг с 64 мегами о... весь текст скрыт [показать]
     
     
  • 11.73, Аноним (-), 10:09, 21/04/2018 [^] [ответить]     [к модератору]  
  • +/
    даже с mysqldump innodb есть фокусы настройки, чтобы заливать дамп быстрее истор... весь текст скрыт [показать]
     
     
  • 12.84, angra (ok), 04:55, 24/04/2018 [^] [ответить]    [к модератору]  
  • +/
    Да уж, заменить hdd на ssd тот еже фокус/настройка. Предлагаю не менее эффективные фокусы/настройки: добавить еще 64 гига памяти и заменить процессор на топовый.
     
  • 11.83, angra (ok), 04:52, 24/04/2018 [^] [ответить]    [к модератору]  
  • +/
    Заметь, что соотношение осталось прежним 1:6
     
  • 9.53, Аноним (-), 13:51, 20/04/2018 [^] [ответить]    [к модератору]  
  • +/
    Это была поправка на конкретное высказывание
    http://www.opennet.ru/openforum/vsluhforumID3/114115.html#12
     
  • 5.39, Валик228 (?), 11:07, 20/04/2018 [^] [ответить]    [к модератору]  
  • +/
    вам бы попробовать дампить базу с ключем --disable-keys

     
  • 3.13, Аноним (-), 01:05, 20/04/2018 [^] [ответить]    [к модератору]  
  • –1 +/
    Статья устаревшая из-за старой используемой версии у Убера. Хотя, конечно, никто не без проблем.
     
     
  • 4.14, KonstantinB (ok), 01:09, 20/04/2018 [^] [ответить]     [к модератору]  
  • +1 +/
    Да пофиг какая версия, основное там - это родовая проблема с организацией данных... весь текст скрыт [показать]
     
  • 3.63, Ilya Indigo (ok), 05:08, 21/04/2018 [^] [ответить]    [к модератору]  
  • +/
    > Postgre пока не нyжен - детально так раъяснено почему - https://habrahabr.ru/company/devconf/blog/353682/

    Благодарю за ссылку! Зачитался и задумался аж на 2 часа.

     
  • 3.81, fi (ok), 14:30, 23/04/2018 [^] [ответить]    [к модератору]  
  • +/
    этот старый вброс давно разобран по косточкам — там в основном проблемы разраба, плюс ему очен хотелось MySQL
     
  • 2.16, rshadow (ok), 01:37, 20/04/2018 [^] [ответить]    [к модератору]  
  • –3 +/
    Постгря плохо работает с индексами. И разрабы абсолютно упираются от создания инструмента ручного управления ими. Так что директивы и невидимые индексы выглядят вкусно.
     
     
  • 3.33, Кабан ЛяЛя (?), 09:11, 20/04/2018 [^] [ответить]    [к модератору]  
  • +1 +/
    Это где она плохо работает?
    Хоть один пример...

    За ручное управление индексами "по шапке"!

     
     
  • 4.41, Аноним (-), 11:12, 20/04/2018 [^] [ответить]    [к модератору]  
  • +/
    Тут не про индексы наверное имелось ввиду а про оптимизатор.
     
     
  • 5.50, rshadow (ok), 13:16, 20/04/2018 [^] [ответить]    [к модератору]  
  • +/
    Ну да. Начиная с COUNT(*) который полным сканированием определяется, заканчивая явными глюками оптимизатора, которые может когда нибудь и починят.
     
     
  • 6.74, Аноним (-), 10:28, 21/04/2018 [^] [ответить]     [к модератору]  
  • +/
    В 5 7, кстати select count чуток ускорили InnoDB SELECT COUNT FROM t sta... весь текст скрыт [показать]
     
  • 4.51, rshadow (ok), 13:21, 20/04/2018 [^] [ответить]     [к модератору]  
  • +/
    Совершенно с вами согласен Только для сферического мира где планировщик не глюч... весь текст скрыт [показать]
     
     ....нить скрыта, показать (56)

  • 1.23, Анонимъ (?), 07:21, 20/04/2018 [ответить] [показать ветку] [···]    [к модератору]  
  • –1 +/
    Ура?
     
     
  • 2.29, Николай (??), 08:05, 20/04/2018 [^] [ответить]    [к модератору]  
  • +1 +/
    > Ура?

    Да

     
  • 1.32, Аноним (-), 09:07, 20/04/2018 [ответить] [показать ветку] [···]    [к модератору]  
  • +/
    Про партицирование ничего не сказали. Его поправили? Можно теперь совмещать в таблице партиции разных движков?
     
     
  • 2.34, Ануним (?), 10:03, 20/04/2018 [^] [ответить]    [к модератору]  
  • –1 +/
    О, помню этот баг. Помнится, из-за него я рабочий проект потребовал на MSSQL перевести.
     
     
  • 3.48, Аноним (-), 12:07, 20/04/2018 [^] [ответить]     [к модератору]  
  • +/
    А мы накостыляли кучу запросов, отображений, триггеров, чтобы работать с разными... весь текст скрыт [показать]
     
     
  • 4.66, Аноним (-), 08:34, 21/04/2018 [^] [ответить]     [к модератору]  
  • +/
    а DATA DIRECTORY не пробовали с партициями https dev mysql com doc refman 5 7... весь текст скрыт [показать]
     
  • 2.65, Аноним (-), 08:29, 21/04/2018 [^] [ответить]     [к модератору]  
  • +/
    Наоборот выпилили эту возможность https dev mysql com doc mysql-partitioning-... весь текст скрыт [показать]
     
  • 1.35, luserz (?), 10:36, 20/04/2018 [ответить] [показать ветку] [···]    [к модератору]  
  • +/
    параллельность добавили выполнения запросов? или всё так же в одну каску молотит каждый запрос?
     
  • 1.36, анонимус (??), 10:52, 20/04/2018 [ответить] [показать ветку] [···]    [к модератору]  
  • +/
    А когда MySQL начнет поддерживать транзакции при изменении структуры таблиц? PostgreSQL это умеет. Я не говорю уже про Oracle/MsSQL.

    Почему я не могу аггрегировать данные в колонку при группировке с сохранением типов? GROUP_CONCAT возвращает строку.

    Когда функция GROUP_CONCAT перестанет тихой сапой резать результирующую строку, в случае если строка превышает значение установленное в group_concat_max_len?

    Такого поведения там полно. И пока его не пофиксят MySQL так и останется недоСУБД.

     
     
  • 2.37, Фуррь (ok), 10:59, 20/04/2018 [^] [ответить]    [к модератору]  
  • +2 +/
    >PostgreSQL это умеет. Я не говорю уже про Oracle/MsSQL.

    Обычно такие претензии возникают из-за непонимания того, что MySQL - это маленькая быстрая пони, и её нельзя грузить, как ломовую лошадь.

     
     
  • 3.76, Адноним (?), 14:34, 22/04/2018 [^] [ответить]    [к модератору]  
  • +/
    Маленькая пони полная Нонна из сомнительных решений и память она жрет в разы больше pgsql
     
  • 2.42, Аноним (-), 11:16, 20/04/2018 [^] [ответить]     [к модератору]  
  • +/
    А когда MySQL начнет поддерживать транзакции при изменении структуры таблиц ... весь текст скрыт [показать]
     
     
  • 3.54, KonstantinB (ok), 15:05, 20/04/2018 [^] [ответить]    [к модератору]  
  • +/
    > А когда MySQL начнет поддерживать транзакции при изменении структуры таблиц?

    Транзакционные системные словари и atomic DDL в 8.0 сделали, так что скоро. Вроде уже ничто не мешает.

     
  • 2.43, Аноним (-), 11:18, 20/04/2018 [^] [ответить]     [к модератору]  
  • +/
    Так она по определению теперь такая, а так-же тестовый полигон и обучалка для бу... весь текст скрыт [показать]
     
  • 2.44, Gemorroj (ok), 11:24, 20/04/2018 [^] [ответить]    [к модератору]  
  • +1 +/
    по 1 пункту - https://dev.mysql.com/doc/refman/8.0/en/data-dictionary.html для этого и делалось.
     
  • 1.47, rvs2016 (ok), 11:45, 20/04/2018 [ответить] [показать ветку] [···]    [к модератору]  
  • +1 +/
    > Версия 8.0 обусловлена сменой нумерации версий,
    > релиз выпущен следом за 5.7 вместо версии 5.8.

    Не понял прикола. Почему в смене версий с 5.7 на сразу 8.0 упор делается на то, что не было промежуточных версий с непонятными номерами типа 5.8 вместо указания на отсутствие более логичных номеров типа 6.0 да 7.0?

    ps: С версиями типа 6.* вроде прикол много лет назад ходил такой: начали делать шестые версии, а потом забросили и откатились обратно на пятые. А с седьмыми номерами прикол какой, в чём?

     
     
  • 2.57, Аноним (-), 19:05, 20/04/2018 [^] [ответить]    [к модератору]  
  • +/
    Тут как с джавой логика, минорная циферка переехала в мажорную, потому что по факту 5.х это давно уже не минорные релизы.
     
     
  • 3.58, Аноним (-), 19:07, 20/04/2018 [^] [ответить]    [к модератору]  
  • +2 +/
    Да и Марию догонять надо :)
     
  • 1.49, Аноним (-), 12:48, 20/04/2018 [ответить] [показать ветку] [···]    [к модератору]  
  • +/
    Чего-то я не понял блокировка строк для обновления дальнейшего в таблице то появилась в транзакции уже? SELECT ... FOR UPDATE?
     
     
  • 2.67, Аноним (-), 08:53, 21/04/2018 [^] [ответить]     [к модератору]  
  • +/
    SELECT FOR UPDATE был уже в 4 0, 2002 год, почти 16 лет назад В 8 0 добавили во... весь текст скрыт [показать]
     
  • 1.60, Vitaliy Blats (?), 20:35, 20/04/2018 [ответить] [показать ветку] [···]    [к модератору]  
  • +2 +/
    Лучше бы не хренотень всякую придумывали, а сделали то, о чем ноют в интернетике с момента создания InnoDB - вменяемого рекавери. Которое именно срекаверит, максимум проигнорирует транзакции с ошибками и восстановит БД, а не высрет в лог кучу непонятной срани, а при попытке восстановить скажет "Ололо Got error: 1146: Table ‘database.table’ doesn’t exist when using бла бла бла"
     
     
  • 2.68, Аноним (-), 09:07, 21/04/2018 [^] [ответить]     [к модератору]  
  • +/
    InnoDB модифицирует данные по месту, Если лог транзакций физически повреждён, то... весь текст скрыт [показать]
     
     
  • 3.77, нах (?), 18:16, 22/04/2018 [^] [ответить]    [к модератору]  
  • +/
    > Если лог транзакций физически повреждён, то на диске могут быть страницы которые ссылаются
    > вникуда (потому что это более свежая версия страницы)

    откатиться на несвежую или уж чорт с ним, потерять содержимое страницы целиком но сохранить остальные данные - не вариант?

     
     
  • 4.79, Аноним (-), 21:49, 22/04/2018 [^] [ответить]     [к модератору]  
  • +/
    В каждой странице содержится ссылка на следующую и предыдущую Если мы сделали с... весь текст скрыт [показать]
     
     
  • 5.80, нах (?), 01:12, 23/04/2018 [^] [ответить]    [к модератору]  
  • +/
    ненене, фатальная проблема с парсингом непойми-чего в том, что мы получим не просто csv, а csv с не факт что нашими данными, а не похожим на них мусором с диска.

    то о чем я спрашивал - это как потерять часть данных (часто это можно себе позволить) но восстановить функционал системы. (то есть не force recovery, а нормальный режим работы, если приложение обломится о неконсистентность связанных таблиц или просто select вернет пустое место - это уже можно как-то переварить самим приложением) Но, видимо, в борьбе за эффективность переэкономили - в результате рухнувшая innodb, получается, вовсе не подлежит оживлению, только выковыривать тем или иным способом данные и пересоздавать ее с нуля (привет от оракла с его ora006).

    binary лог к сожалению не панацея - он-то может и быстро накатиться, да вот восстановление самой крупной базы займет неприлично много времени.

     

     Добавить комментарий
    Имя:
    E-Mail:
    Заголовок:
    Текст:


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