https://www.opennet.me/openforum/vsluhforumID3/114115.html После двух с половиной лет разработки компания Oracle представила (https://mysqlserverteam.com/whats-new-in-mysql-8-0-generally-available/) первый стабильный релиз СУБД 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.<br><br><br><br><br><br><br>Ключевые улучшения (http://dev.mysql.com/doc/refman/8.0/en/mysql-nutshell.html) MySQL 8.0:<br><br><br>- Добавлен (https://mysqlserverteam.com/mysql-8-0-announcing-ga-of-the-mysql-document-store/) режим работы в качестве хранилища документов (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-concepts.html) без предварительно определяемой схемы хранения). Функциональность реализов https://www.opennet.me/openforum/vsluhforumID3/114115.html#87 Tue, 04 Dec 2018 20:45:00 GMT Мда.. вышел порт 8.0.12_1, затем 8.0.12_2 и не собирается.. откатывать обратно на 5.7...<br><br>mysql80-server-8.0.12_2 is vulnerable:<br>MySQL -- multiple vulnerabilities<br>CVE: CVE-2018-3286<br>CVE: CVE-2018-3283<br>CVE: CVE-2018-3284<br>CVE: CVE-2018-3282<br>CVE: CVE-2018-3279<br>CVE: CVE-2018-3278<br>CVE: CVE-2018-3161<br>CVE: CVE-2018-3186<br>CVE: CVE-2018-3280<br>CVE: CVE-2018-3212<br>CVE: CVE-2018-3170<br>CVE: CVE-2018-3200<br>CVE: CVE-2018-3173<br>CVE: CVE-2018-3162<br>CVE: CVE-2018-3277<br>CVE: CVE-2018-3171<br>CVE: CVE-2018-3174<br>CVE: CVE-2018-3187<br>CVE: CVE-2018-3247<br>CVE: CVE-2018-3195<br>CVE: CVE-2018-3185<br>CVE: CVE-2018-3144<br>CVE: CVE-2018-3145<br>CVE: CVE-2018-3133<br>CVE: CVE-2018-3203<br>CVE: CVE-2018-3137<br>CVE: CVE-2018-3182<br>CVE: CVE-2018-3251<br>CVE: CVE-2018-3156<br>CVE: CVE-2018-3143<br>CVE: CVE-2018-3155<br>CVE: CVE-2016-9843<br>WWW: https://vuxml.FreeBSD.org/freebsd/ec5072b0-d43a-11e8-a6d2-b499baebfeaf.html<br> https://www.opennet.me/openforum/vsluhforumID3/114115.html#86 Tue, 24 Apr 2018 19:31:33 GMT &gt; одни и те же данные будут и в shared memory и в кеше ОС<br><br>Как долго? Это не так просто оценить, у shared_buffers и у кеша ОС есть алгоритмы вытеснения не используемых данных, в конечном счёте в shared_buffers останутся горячие данные, а в кеше ОС &#8212; тёплые (другие), потому что данные находящиеся в shared_buffers не запрашиваются у ОС и вытесняются из кеша, не так ли?<br> https://www.opennet.me/openforum/vsluhforumID3/114115.html#84 Tue, 24 Apr 2018 01:55:38 GMT Да уж, заменить hdd на ssd тот еже фокус/настройка. Предлагаю не менее эффективные фокусы/настройки: добавить еще 64 гига памяти и заменить процессор на топовый. <br> https://www.opennet.me/openforum/vsluhforumID3/114115.html#83 Tue, 24 Apr 2018 01:52:02 GMT Заметь, что соотношение осталось прежним 1:6<br> https://www.opennet.me/openforum/vsluhforumID3/114115.html#82 Mon, 23 Apr 2018 18:01:40 GMT А вот так они могут? :-)<br>https://www.reddit.com/r/brainfuck/comments/83cw7l/i_implemented_a_brainfck_interpreter_in_pure_sql/<br><br>C рекурсивным CTE, кстати, MySQL-евский диалект SQL стал тьюринг-полным языком. :-)<br> https://www.opennet.me/openforum/vsluhforumID3/114115.html#81 Mon, 23 Apr 2018 11:30:48 GMT этот старый вброс давно разобран по косточкам &#8212; там в основном проблемы разраба, плюс ему очен хотелось MySQL<br> https://www.opennet.me/openforum/vsluhforumID3/114115.html#80 Sun, 22 Apr 2018 22:12:07 GMT ненене, фатальная проблема с парсингом непойми-чего в том, что мы получим не просто csv, а csv с не факт что нашими данными, а не похожим на них мусором с диска.<br><br>то о чем я спрашивал - это как потерять часть данных (часто это можно себе позволить) но восстановить функционал системы. (то есть не force recovery, а нормальный режим работы, если приложение обломится о неконсистентность связанных таблиц или просто select вернет пустое место - это уже можно как-то переварить самим приложением) Но, видимо, в борьбе за эффективность переэкономили - в результате рухнувшая innodb, получается, вовсе не подлежит оживлению, только выковыривать тем или иным способом данные и пересоздавать ее с нуля (привет от оракла с его ora006).<br><br>binary лог к сожалению не панацея - он-то может и быстро накатиться, да вот восстановление самой крупной базы займет неприлично много времени.<br><br> https://www.opennet.me/openforum/vsluhforumID3/114115.html#79 Sun, 22 Apr 2018 18:49:57 GMT &gt; откатиться на несвежую или уж чорт с ним, потерять содержимое страницы целиком но сохранить остальные данные - не вариант?<br><br>В каждой странице содержится ссылка на следующую и предыдущую. Если мы сделали сплит (одну страницу поменяли по месту и уже потеряли ссылку на старую следующую), а новую страницу потеряли при записи на диск, то всё пропало - потеряли связь со всеми последующими страницами.<br><br>У innodb нет версий страниц, страницы меняются по месту. Есть версии строк - (старые строчки пишутся в undo segment), но это не поможет если вместо следующей странички указатель ведёт на мусор.<br><br>Так что получается или втупую парсить, или пытаться по кускам делать select .. where из-под force recovery.<br>Ну и если словарь повреждён то пытаться делать ibdconnect.<br><br>Фатальный недостаток парсинга - все данные в csv виде на выходе и для терабайтной базы это всё надо ещё пару недель грузить.<br><br><br>Потенциально можно сделать поиск "потерянных деревьев" страниц, но будут левые данные и несогласованные данные в табличках https://www.opennet.me/openforum/vsluhforumID3/114115.html#78 Sun, 22 Apr 2018 18:38:30 GMT &gt; То, что сейчас кажется дикостью, 20 лет назад было оптимальным решением.<br><br>и пока линуксеры не доломали совместимость с нормальными юниксами - вполне пристойно работает.<br><br>родовая травма постгреза - его причудливейший формат storage, корнями уходящий в великую бесполезно-фичу time-travel (не работающую со времен postgresql95)<br><br>с вечным vacuum ("мы его уже совсем-совсем deprecated, он ненужен-ненужен...а, нет, разумеется он будет и дальше вызываться из внутреннего планировщика в самые неподходящие моменты, мы не об этом") и вечным разрастанием индексов.<br>Что новый-модный zheap решит эти проблемы не создав попутно все те же что у myisam и еще пачку уникальных - что-то вот не верится.<br><br><br><br>