Не, ну а вдруг. И не сильно чтобы пригорает, но все-таки. Дано: база mysql 5.7, 25 ГБ в бинарниках, 23 ГБ в дампе. 400+ таблиц innodb. Боевой сервер: 16 вирт. ядер Xeon-чего-то-там (облако) 16G RAM. Локальный сервер: Аквариус E50 D36, 16 ядер 2×Xeon 16G DDR4, SSD INTEL SSDSC2KG24. Нужно локальный сервер периодически синхронизировать с боевым, чтобы делать локально всякие штуки-дрюки, которые на боевом низя. Код: mysqldump -uroot --opt --quick --no-autocommit > dump.sql Дамп создается 16-18 минут. Восстановление из дампа: при дефолтных настройках mysql-server ≈ 3,5 часа подкрутил настройки, как на боевом сервере*, и максимум, что выжал, это 2,25 ч. Спойлер: * 200-300 запросов в секнуду, какой-никакой, а хайлоад. Методом тыка натыкал Код: innodb_buffer_pool_size = 12G innodb-buffer-pool-instances = 8 innodb_buffer_pool_chunk_size = 128M innodb_log_file_size = 1G innodb_flush_method = O_DSYNC innodb_flush_log_at_trx_commit=2 max_allowed_packet = 512M max_connections = 6144 thread_cache_size = 800 Но это все хорошо для боевого сервера, а для никак не нагруженного (толпой юзверей) локального помогло не сильно. Знаю, что есть коммерческое решение от оракеля, но воспользоваться нереально, ибо мы госы, у нас бюрократия будет месяц сопли жевать. Читал, у перконы есть решение, но насколько оно работоспособно на ванильном мускуле, не понял. Ну и кучка сомнительных советов сплясать с бубном, чтобы копия бинарников БД ожила на другом сервере. Просто так, с наскоку, у меня не ожила. P.S. Да, я знаю ключевое слово postgre. Знал бы,где упасть, соломки подстелил, знал бы прикуп, жил бы в Сочи, и т.д. P.P.S. Полное впечатление, что оракель сознательно затормозил клиент mysql, чтобы покупали коммерческую бэкапилку. Ну что это за херь, два зиона, 16G — а загрузка CPU всего-то 6-8%, дисковый IO 15-25 МБ/с, и никак не разгоняется.
я в основном из бд с постгрей работал и под виндой не знаю взлетит ли у вас такое, но если для баловства и побыстрее то почему нет я попробовал бы теневую копию папки с данными дернуть на лету, серверу не мешало бы
Я бы покопал в сторону репликации, при беглом осмотре первых результатов поиска, бывает какой-то режим "мастер - пассивный мастер", который вроде как подходит под ваш сценарий экспериментов на локальном сервере.
Файлопомойку я могу снапшотить в любой момент, но база лежит на другой виртуалке, в файловой системе ext4, которая в снапшоты не умеет. Ну и снапшотить файлы БД на лету так себе идея. Остановить, чтобы сервер БД сбросил кэши, это да. Но затык-то вовсе не в том месте. В сторону репликации тоже посмотрел, но тут есть неочевидная засада. Имеется файлопомойка, почти терабайт весом, жестко привязанная к базе, которая постоянно модифицируется. Нельзя просто так взять, и асинхронно сделаьь слепки отдельно с каталога БД и отдельно каталога фалохранилища. ВОПРОС БЫЛ НЕ ОБ ЭТОМ! Я ночью сегодня остановил mysql сервер, скопировал каталог базы на локальный сервер и получил неработающую базу. Сплошная ругань типа: Код: 2021-04-16T01:53:47.700351Z 3 [ERROR] InnoDB: Failed to find tablespace for table `service_moodle`.`mdl_workshop_grades` in the cache. Attempting to load the tablespace with space id 1376 2021-04-16T01:53:47.700463Z 3 [ERROR] InnoDB: In file './service_moodle/mdl_workshop_grades.ibd', tablespace id and flags are 625 and 41, but in the InnoDB data dictionary they are 1376 a 2021-04-16T01:53:47.700477Z 3 [ERROR] InnoDB: Operating system error number 2 in a file operation. 2021-04-16T01:53:47.700489Z 3 [ERROR] InnoDB: The error means the system cannot find the path specified. 2021-04-16T01:53:47.700501Z 3 [ERROR] InnoDB: Could not find a valid tablespace file for `service_moodle/mdl_workshop_grades`. Please refer to http://dev.mysql.com/doc/refman/5.7/en/innod 2021-04-16T01:53:47.700593Z 3 [Warning] InnoDB: Cannot calculate statistics for table `service_moodle`.`mdl_workshop_grades` because the .ibd file is missing. Please refer to http://dev.m Насколько понимаю, кроме каталога самой базы в деле участвуют более другие файлы со всякими там журналами. На нынешнюю ночь зарядил в довесок к обычному бэкапу склонировать все, что смог найти относящееся к мускулю. Посмотрим.
на винде, поди? На винде крутить всё, кроме mssql, стремная идея, имхо. И таки да, мускуль под линуксом не подвисает и на стогиговой, но вот старый хоткопи у него Оракель запорол, а новым за бабки барыжит. А, не вкурил сразу. Надо бы мануал почитать, по идее, что-то там про журналы транзакций и их восстановление масса всякого понаписана. Если б я был таки дибэйс-админом, а не «Анатольич, не посмотришь? Можешь что-то с этим сделать?» ... извечная моя беда — мне людей жалко.
не могу сказать ни твердого да ни нет. пожалуй бывали недели беспечнее. состояние дел на работе мотивирует развиваться в другом месте.
SET FOREIGN_KEY_CHECKS=0; SET UNIQUE_CHECKS=0; SET AUTOCOMMIT=0; Перед восстановлением. Можно добавить в дамп в хидер: SET @OLD_AUTOCOMMIT=@@AUTOCOMMIT, AUTOCOMMIT = 0; SET @OLD_UNIQUE_CHECKS=@@UNIQUE_CHECKS, UNIQUE_CHECKS = 0; SET @OLD_FOREIGN_KEY_CHECKS=@@FOREIGN_KEY_CHECKS, FOREIGN_KEY_CHECKS = 0; А это в футер: SET FOREIGN_KEY_CHECKS=@OLD_FOREIGN_KEY_CHECKS; SET UNIQUE_CHECKS=@OLD_UNIQUE_CHECKS; SET AUTOCOMMIT = @OLD_AUTOCOMMIT; COMMIT;
всё тут очевидно репликация = минимальнейшая задержка по синхронизации бд, снапшот файлопомойки делаешь и получаешь только конфликт с файлами из файлопомойки изменёнными пока делался снапшот. там вручную решаешь конфликты
Обижаешь, начальник. © Я, понятно, старый пень с замшелыми мозгами, но не до такой же степени. Код: -- MySQL dump 10.13 Distrib 5.7.33, for Linux (x86_64) -- -- Host: localhost Database: service_moodle -- ------------------------------------------------------ -- Server version 5.7.33-0ubuntu0.18.04.1 /*!40101 SET @OLD_CHARACTER_SET_CLIENT=@@CHARACTER_SET_CLIENT */; /*!40101 SET @OLD_CHARACTER_SET_RESULTS=@@CHARACTER_SET_RESULTS */; /*!40101 SET @OLD_COLLATION_CONNECTION=@@COLLATION_CONNECTION */; /*!40101 SET NAMES utf8 */; /*!40103 SET @OLD_TIME_ZONE=@@TIME_ZONE */; /*!40103 SET TIME_ZONE='+00:00' */; /*!40014 SET @OLD_UNIQUE_CHECKS=@@UNIQUE_CHECKS, UNIQUE_CHECKS=0 */; /*!40014 SET @OLD_FOREIGN_KEY_CHECKS=@@FOREIGN_KEY_CHECKS, FOREIGN_KEY_CHECKS=0 */; /*!40101 SET @OLD_SQL_MODE=@@SQL_MODE, SQL_MODE='NO_AUTO_VALUE_ON_ZERO' */; /*!40111 SET @OLD_SQL_NOTES=@@SQL_NOTES, SQL_NOTES=0 */; *** Код: LOCK TABLES `mdl_analytics_indicator_calc` WRITE; /*!40000 ALTER TABLE `mdl_analytics_indicator_calc` DISABLE KEYS */; set autocommit=0; и далее автокоммит отключен для всех таблиц, ибо: Код: mysqldump -uroot --opt --quick --no-autocommit > dump.sql 25 гигов база и 803 гига помойка с почти миллионом файлов. С вашего позволения, я не буду даже думать про рукопашную борьбу. (галимый оффтопик) percona кто-нить юзает? Как оно по сравнению с ванилой и марией? 2 @The Chief, когда я это все добавил, скорость не прибавилась от слова ни...я. Насколько могу судить, ускорение 3,5 часа → 2,25 часа произошло по причине увеличения лимитов на всевозможные кэши и буферы. Но дальше я уперся в упорнное неиспользование ресурсов связкой клиент→сервер.
@027, опции --disable-keys и --extended-insert при создании бэкапа пробовал? PS: mysqlimport, как вариант.
ну тут чекпоинт для бд и файломойки по который заснепшотит, я хз есть ли продукты которые позволяют так сделать, есть подозрение что нету, поэтому нужно будет пилить что-то самопальное
@The Chief, (Я заранее прошу прощения, ибо башка совсем уже не шурупит. Как у начальства заискрило в... неважно. Так я и впахивал со вторника, пока не уяснил и не притушил слегка самипонимаетечто.) Смотрю в мануал: Ну... типа да. А нет подозрения, что как раз этим я и занимаюсь? ))) (хотя за каким лядом мне оно все надо... беда моя, как я и говорил, что мне людей жалко... сил нету смотреть, как они сотни часов механическую рутину перелопачивают, когдя чсно вижу, как это может сделать дешевая железяка)
не, есть ощущение, что покачто вы на этапе исследования ускорения стандартных действий для выгрузки и разворота снапшота но на мой взгляд это тупиковый путь, нужно четко по чекпоинту действовать и время разворота тут не важно
last commit 4 years ago Спасибо, шеф! ))) Снапшотами FS я обмазался с ног до головы, выражаясь нынешним сленгом. И на работе, и дома. Очень полезная штука, но здесь неприменима.
аааа! я же говорю, мой старческий моск упоролся нынче в хлам впрочем, ладно вы же это не использовали никогда, чисто нагуглили? как и я, кучу подобных рецептов, за которыми никакой гарантии успеха, кроме перспективы убить массу времени
Я его использовал года полтора назад. Он удобный. А потом я избавился от мускуля и перекрестился, потому что это унылое тормозное говно и для баз >1Гб (ну ладно, больше двух-трёх) непригодно в принципе. Можете пробовать Percona, её хвалят. У меня руки не дошли. Но принцип там тот же самый — разбиение задачи и параллелизация. Ибо мускуль тупой и сам не умеет.
«поздно, Клава, пить боржоми» до сих пор никаких проблем, летает пулей, никаких сбоев 25 гигов, напомню Сей инстанс выдержал три или четыре панических переезда с сервера на сервер, по мере внезапного стремительного роста нагрузки. И это с учетом моих кривых лапок, впервые ковырявшихся в хайлоаде.
А так все зашибись. Летает пулей. И не надо мне тут. У меня банальная сисЬтема дистанционного образования, а не биржа с очумевшими трейдерами.
«Сам я Павла не видал, но ты не надейся» Ну, ок. Собсно, см. первое слово топика. @The Chief, надеюсь, не обиделись. На самом деле я вам благодарен за сочувствие.