После двух с половиной лет разработки компания 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
Спасибо, но уже есть PostgreSQL и MariaDB.
Это лучше, чем MariaDB, они выпилили myisam насовсем, в том числе из служебных таблиц.
Aria?
Фигария, попробуй сменить тип таблиц в базе mysql.
https://dev.mysql.com/doc/refman/8.0/en/data-dictionary.html
вот тоже уже думаю обратно на ванильный mysql с марии переезжать.
честный json, sys схема... в то время как мария начала ломать совместимость с оригинальным mysql (тот же json), что сильно снижает ее привлекательность.
Еще CTE и window-функции завезли.Я с бетой игрался, отлично, уже прям настоящая РСУБД, скоро постгрес догонит.
я пока заткнулся с https://dev.mysql.com/doc/refman/8.0/en/mysql-secure-install...# mysql_secure_installationSecuring the MySQL server deployment.
Connecting to MySQL using a blank password.
Segmentation fault
> Segmentation faultОбычно перестаёт быть страшно к N.X.20-26, а в важных местах к N.X.40
Но ходят слухи, что минорная нумерация версий тоже поменяется/поменялась.
Percona умеет половину из Maria и Mysql 8.0
> Percona умеет половину из Maria и Mysql 8.0Transactional data dictionary не умеют, это самое главное. Тут я восхищаюсь объемом проделанной работы. Системные словари относятся к самому древнему окаменевшему коду, который Монти писал на коленке в далеких девяностых, и myisam был прибит гвоздями наглухо кондовым хардкодом везде, где можно и нельзя.
myisam гогно, тут я с вами согласен на все 100%
> Percona умеет половину из Maria и Mysql 8.0Percona не пилит новые божественные фичи. Percona Server это ванильный оракловый MySQL + набор фишек повышающих производительность (чаще меньше чем следующий мажорный релиз от Oracle) + удобства диагностики (больше инфы в slowlog, userstats) + энтерпрайз фишки под GPL вроде PAM audit_plugin.
MariaDB пилят свои фишки отдельно, на своём форке mysql 5.5, без оглядки что это надо/можно будет объединить с Oracle MySQL.
Так что Percona Server 8.0 выйдет через пару месяцев и будет уметь то же что и MySQL 8.0, а фишки из MariaDB доступны только плагинные.
Никакой магии нет, все три компании занимаются разным в плане разработки.
А вот так они могут? :-)
https://www.reddit.com/r/brainfuck/comments/83cw7l/i_impleme.../C рекурсивным CTE, кстати, MySQL-евский диалект SQL стал тьюринг-полным языком. :-)
мария начала ломать совместимость с оригинальным mysql хорошая шутка.
ну поработай с json, найди там хоть какой-то сходство.
я про то что оригинальный MySQL это и есть мария.
https://jira.mariadb.org/browse/MDEV-13594
Ответ на мой комментарий меня просто поразил.
Я после того подумал про миграцию на PostgreSQL.
Postgre пока не нyжен - детально так раъяснено почему - https://habrahabr.ru/company/devconf/blog/353682/
Чтобы с озвученной Uber-ом проблемой столкнуться, нужен особый характер нагрузки - множество апдейтов в секунду, затрагивающих индекс. Для большинства проектов это не критично.
Из статьи следует, что апдейты индексированнного поля и неиндексированного одинаково тяжеловесны в Постгри.
Использование СУБД файлового кеша ОСи убило ваапще.Подумывал опробывать Постги, но теперь обожду.
> Использование СУБД файлового кеша ОСи убило ваапще.И чем же?
>> Использование СУБД файлового кеша ОСи убило ваапще.
> И чем же?Если горячая страничка (на чтение) вытеснится из кеша ОС, сразу пачка одновременных запросов может заблокироваться, за это время придёт ещё пачка запросов и база будет работать медленнее из-за скачка нагрузки (больше тредов/процессов - больше блокировок).
Эту проблему можно убрать, если кешировать в shared memory сегменте базы, но без direct io одни и те же данные будут и в shared memory и в кеше ОС, а значит надо для одних и тех же данных закупать на 20-30% больше оперативной памяти если база не работает/не эфективно работает с direct io.
> одни и те же данные будут и в shared memory и в кеше ОСКак долго? Это не так просто оценить, у shared_buffers и у кеша ОС есть алгоритмы вытеснения не используемых данных, в конечном счёте в shared_buffers останутся горячие данные, а в кеше ОС — тёплые (другие), потому что данные находящиеся в shared_buffers не запрашиваются у ОС и вытесняются из кеша, не так ли?
То, что сейчас кажется дикостью, 20 лет назад было оптимальным решением. Хранилище постгреса проектировалось в те далекие времена, когда никаких O_DIRECT не было даже в планах. В условиях какого-нибудь ядра 1.4 или freebsd 3 это было наиболее эффективным решением. Оттуда же и пачки процессов и shared memory - никаких epoll-ов и прочих kevent тоже не было, с тредами все было печально. Но, надо заметить, все это и сейчас весьма неплохо работает.
> То, что сейчас кажется дикостью, 20 лет назад было оптимальным решением.и пока линуксеры не доломали совместимость с нормальными юниксами - вполне пристойно работает.
родовая травма постгреза - его причудливейший формат storage, корнями уходящий в великую бесполезно-фичу time-travel (не работающую со времен postgresql95)
с вечным vacuum ("мы его уже совсем-совсем deprecated, он ненужен-ненужен...а, нет, разумеется он будет и дальше вызываться из внутреннего планировщика в самые неподходящие моменты, мы не об этом") и вечным разрастанием индексов.
Что новый-модный zheap решит эти проблемы не создав попутно все те же что у myisam и еще пачку уникальных - что-то вот не верится.
Чтобы с этой проблемой столкнуться надо написать оптимизированную логику под MySQL, а потом перенести эту логику на Postgres. У которой свои оптимизации.>>Для большинства проектов это не критично.
Postgres не любит апдейтов, как и любой версионник. Для кучи апдейтов лучше уж NoSQL использовать.
Извините, но Innodb тоже версионник. Однока он лучше сравляется спробоемой потому, что у него быстрее всего доступна именно последняя версия строки.В постгрессе же последняя версия строки чаще всего попадает в экзкьютор последней.
Не нужен кому? PostgreSQL это из разряда MSSQL, продукции Oracle, Sybase.З.Ы. топить за MyISAM не смешно и не весело ни разу.
А чем myisam плох для определённых случаев? Вот есть десяток девелоперских баз. На myisam заливка дампа на два с половиной гигабайта с прода занимает от силы 10 минут. На Inno/XtraDB - в лучшем случае час, и всякие игрища с параметрами в my.cnf и системной схеме не особо помогают.
Для девелоперской базы никто не мешает остановить mysqld и ручками скопировать innodb-файлы.
Потом попробовать стартануть мускул, почитать ругань, а если он таки стартанул, то попытаться найти таблицы и обнаружить их отсутствие. Повторить процесс такого горячего копирования несколько раз, до тех пор пока не придет осознание, что ты что-то делаешь неправильно. Потом пойти почитать про кучу дополнительных телодвижений и условий, необходимых для использования такого метода с innodb.
Ничего сложного, совсем.
Во-первых, можно скопировать содержимое /var/lib/mysql вообще целиком
Во-вторых, если хочется частично, https://dev.mysql.com/doc/refman/5.6/en/innodb-migration.html
> Ничего сложного, совсем.Я не говорил, что сложно или невыполнимо. Но простое копирование как с MYISAM приведет к проблемам.
> Во-первых, можно скопировать содержимое /var/lib/mysql вообще целиком
Можно и не такие глупости сделать, но зачем? Задача то ведь несколько другая была.
> Во-вторых, если хочется частично, https://dev.mysql.com/doc/refman/5.6/en/innodb-migration.html
А ты прочитать содержимое своей ссылки пробовал? Вдруг окажется, что там ровно то, что я и говорил: "кучу дополнительных телодвижений и условий, необходимых для использования такого метода с innodb."
Да ладно куча, элементарно все.
> Задача то ведь несколько другая былаЗадача была импортировать данные на машину разработчика. Для этого можно и так сделать.
А можно вообще сделать "грязный" rsync, после чего стопнуть слейв на минутку и сделать еще один.
>> Во-вторых, если хочется частично, 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 чтобы копировать/востанавливать параллельно.
Если останавливают процессы, то это не горячее а холодное копирование.
Из контекста остановка продакшена не предусматривалась и про использование реплики не говорилось.
> Из контекста остановка продакшена не предусматривалась и про использование реплики не говорилось.В общем вместо чтения документации - каждый на своей волне :)
Вообще-то там речь о девелоперских базах шла.И что это такой за продакшен без реплики или xtrabackup?
> Вообще-то там речь о девелоперских базах шла.
> И что это такой за продакшен без реплики или xtrabackup?там может быть все что угодно. например 386DX2... какой-то хостинг с 64 мегами озу и низвестно что еще. Потому что 2,5 гига он заливает час...
У меня это происходит несколько быстрее:
./load_test.sh
load innodbreal 2m21.104s
user 0m8.648s
sys 0m1.101s
load isamreal 0m26.690s
user 0m8.809s
sys 0m1.233s
./dump_test.sh
dump innodbreal 0m11.196s
user 0m9.231s
sys 0m1.441s
dump isamreal 0m11.911s
user 0m9.563s
sys 0m1.435s
> там может быть все что угодно. например 386DX2... какой-то хостинг с 64
> мегами озу и низвестно что еще. Потому что 2,5 гига он
> заливает час...
> У меня это происходит несколько быстрее:даже с mysqldump+innodb есть фокусы/настройки, чтобы заливать дамп быстрее
история о сокращение востановления бекапа с двух часов (дефолтовые настройки, hdd) до 15 минут (ssd, настройки, параллельная загрузка):
https://www.percona.com/blog/2018/02/22/restore-mysql-logica.../Ну и есть mydumper с которым тоже можно быстро бекапить/загружать.
Да уж, заменить hdd на ssd тот еже фокус/настройка. Предлагаю не менее эффективные фокусы/настройки: добавить еще 64 гига памяти и заменить процессор на топовый.
Заметь, что соотношение осталось прежним 1:6
Это была поправка на конкретное высказывание
http://www.opennet.dev/openforum/vsluhforumID3/114115.html#12
вам бы попробовать дампить базу с ключем --disable-keys
Статья устаревшая из-за старой используемой версии у Убера. Хотя, конечно, никто не без проблем.
Да пофиг какая версия, основное там - это родовая проблема с организацией данных. Из-за нее, кстати, и нужен тяжелый VACUUM. Патчи в новых версиях только смягчают проблему, но не решают.Все остальные пункты - действительно мелкие придирки.
> Postgre пока не нyжен - детально так раъяснено почему - https://habrahabr.ru/company/devconf/blog/353682/Благодарю за ссылку! Зачитался и задумался аж на 2 часа.
этот старый вброс давно разобран по косточкам — там в основном проблемы разраба, плюс ему очен хотелось MySQL
Постгря плохо работает с индексами. И разрабы абсолютно упираются от создания инструмента ручного управления ими. Так что директивы и невидимые индексы выглядят вкусно.
Это где она плохо работает?
Хоть один пример...За ручное управление индексами "по шапке"!
Тут не про индексы наверное имелось ввиду а про оптимизатор.
Ну да. Начиная с COUNT(*) который полным сканированием определяется, заканчивая явными глюками оптимизатора, которые может когда нибудь и починят.
> Ну да. Начиная с 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... так что надо смотреть как оно на реальных запросах и базах будет помогать.
Совершенно с вами согласен. Только для сферического мира где планировщик не глючит, ALTER TABLE...NOT NULL всегда делается мгновенно на боевой бд, и вообще есть беспростойный апгрейд версии через репликацию.
Очень хочется просто вводить команды, а оно само оптимизировалось, расползалось по кластеру, делалось мгновенно и без глюков.
Ура?
> Ура?Да
Про партицирование ничего не сказали. Его поправили? Можно теперь совмещать в таблице партиции разных движков?
О, помню этот баг. Помнится, из-за него я рабочий проект потребовал на MSSQL перевести.
А мы накостыляли кучу запросов, отображений, триггеров, чтобы работать с разными устройствами хранения данных в рамках одной таблицы. Хотя фактически это были разные таблицы. В итоге забили, перевели на SSD, которые мрут как мухи, но обеспечивают стабильную поддержку ПО.
Не понятно, зачем вводить в протокол функционал, который они и не собирались поддерживать. Подразнить?...
> А мы накостыляли кучу запросов, отображений, триггеров, чтобы работать с разными устройствами
> хранения данных в рамках одной таблицы.а DATA DIRECTORY не пробовали с партициями? https://dev.mysql.com/doc/refman/5.7/en/partitioning-subpart...
Наоборот выпилили эту возможность:
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.
параллельность добавили выполнения запросов? или всё так же в одну каску молотит каждый запрос?
А когда MySQL начнет поддерживать транзакции при изменении структуры таблиц? PostgreSQL это умеет. Я не говорю уже про Oracle/MsSQL.Почему я не могу аггрегировать данные в колонку при группировке с сохранением типов? GROUP_CONCAT возвращает строку.
Когда функция GROUP_CONCAT перестанет тихой сапой резать результирующую строку, в случае если строка превышает значение установленное в group_concat_max_len?
Такого поведения там полно. И пока его не пофиксят MySQL так и останется недоСУБД.
>PostgreSQL это умеет. Я не говорю уже про Oracle/MsSQL.Обычно такие претензии возникают из-за непонимания того, что MySQL - это маленькая быстрая пони, и её нельзя грузить, как ломовую лошадь.
Маленькая пони полная Нонна из сомнительных решений и память она жрет в разы больше pgsql
> А когда 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.
> А когда MySQL начнет поддерживать транзакции при изменении структуры таблиц?Транзакционные системные словари и atomic DDL в 8.0 сделали, так что скоро. Вроде уже ничто не мешает.
> Такого поведения там полно. И пока его не пофиксят MySQL так и
> останется недоСУБД.Так она по определению теперь такая, а так-же тестовый полигон и обучалка для будущего использования промышленной БД от oracle.
по 1 пункту - https://dev.mysql.com/doc/refman/8.0/en/data-dictionary.html для этого и делалось.
> Версия 8.0 обусловлена сменой нумерации версий,
> релиз выпущен следом за 5.7 вместо версии 5.8.Не понял прикола. Почему в смене версий с 5.7 на сразу 8.0 упор делается на то, что не было промежуточных версий с непонятными номерами типа 5.8 вместо указания на отсутствие более логичных номеров типа 6.0 да 7.0?
ps: С версиями типа 6.* вроде прикол много лет назад ходил такой: начали делать шестые версии, а потом забросили и откатились обратно на пятые. А с седьмыми номерами прикол какой, в чём?
Тут как с джавой логика, минорная циферка переехала в мажорную, потому что по факту 5.х это давно уже не минорные релизы.
Да и Марию догонять надо :)
Чего-то я не понял блокировка строк для обновления дальнейшего в таблице то появилась в транзакции уже? SELECT ... FOR UPDATE?
> Чего-то я не понял блокировка строк для обновления дальнейшего в таблице то
> появилась в транзакции уже? SELECT ... FOR UPDATE?SELECT FOR UPDATE был уже в 4.0, 2002 год, почти 16 лет назад.
В 8.0 добавили возможность при использовании select for update либо выдать ошибку как только натолкнёмся на строчку заблокированную другой транзакцией NOWAIT (модифицированную или заблокированную S F U) либо молча пропускать строчки заблокированные другими транзакциями SKIP LOCKED.
Сходу что приходит в голову, такие фишки позволяют делать очереди с несколькими обработчиками на кроне/event scheduler.
Лучше бы не хренотень всякую придумывали, а сделали то, о чем ноют в интернетике с момента создания InnoDB - вменяемого рекавери. Которое именно срекаверит, максимум проигнорирует транзакции с ошибками и восстановит БД, а не высрет в лог кучу непонятной срани, а при попытке восстановить скажет "Ололо Got error: 1146: Table ‘database.table’ doesn’t exist when using бла бла бла"
> Лучше бы не хренотень всякую придумывали, а сделали то, о чем ноют
> в интернетике с момента создания 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 будут те же самые проблемы с аварийным востановлением.
> Если лог транзакций физически повреждён, то на диске могут быть страницы которые ссылаются
> вникуда (потому что это более свежая версия страницы)откатиться на несвежую или уж чорт с ним, потерять содержимое страницы целиком но сохранить остальные данные - не вариант?
> откатиться на несвежую или уж чорт с ним, потерять содержимое страницы целиком но сохранить остальные данные - не вариант?В каждой странице содержится ссылка на следующую и предыдущую. Если мы сделали сплит (одну страницу поменяли по месту и уже потеряли ссылку на старую следующую), а новую страницу потеряли при записи на диск, то всё пропало - потеряли связь со всеми последующими страницами.
У innodb нет версий страниц, страницы меняются по месту. Есть версии строк - (старые строчки пишутся в undo segment), но это не поможет если вместо следующей странички указатель ведёт на мусор.
Так что получается или втупую парсить, или пытаться по кускам делать select .. where из-под force recovery.
Ну и если словарь повреждён то пытаться делать ibdconnect.Фатальный недостаток парсинга - все данные в csv виде на выходе и для терабайтной базы это всё надо ещё пару недель грузить.
Потенциально можно сделать поиск "потерянных деревьев" страниц, но будут левые данные и несогласованные данные в табличках и совершенно не ясно что делать, если у страницы неверная контрольная сумма, так что лучше делать бекапы и point-in-time с помощью binary log.
ненене, фатальная проблема с парсингом непойми-чего в том, что мы получим не просто csv, а csv с не факт что нашими данными, а не похожим на них мусором с диска.то о чем я спрашивал - это как потерять часть данных (часто это можно себе позволить) но восстановить функционал системы. (то есть не force recovery, а нормальный режим работы, если приложение обломится о неконсистентность связанных таблиц или просто select вернет пустое место - это уже можно как-то переварить самим приложением) Но, видимо, в борьбе за эффективность переэкономили - в результате рухнувшая innodb, получается, вовсе не подлежит оживлению, только выковыривать тем или иным способом данные и пересоздавать ее с нуля (привет от оракла с его ora006).
binary лог к сожалению не панацея - он-то может и быстро накатиться, да вот восстановление самой крупной базы займет неприлично много времени.
Мда.. вышел порт 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...