MySQL копии к RAM как memcached замена бедного человека?
Во-первых: Сделайте резервное копирование текущего состояния. Затем, если это возможно, попытайтесь только восстановить недостающие файлы из одного из более старых изображений (должно быть возможно смонтировать изображение и получить доступ к нему как жесткий диск). Если Ваше решение по оцифровке не признает, что, восстановите изображение к резервному диску и скопируйте файлы оттуда.
Используйте механизм хранения MEMORY на ведомом устройстве только для чтения для чтения, это именно то, что вы действительно хотите, и разумная установка. Забудьте «выгружать его на диск» (?!) Или другие странные вещи.
Вы даже можете поместить подчиненное устройство в качестве другого экземпляра на существующий сервер, если вы не можете позволить себе установить выделенное подчиненное устройство, но правильно настроили параметры MySQL для рабочих нагрузок, в основном считываемых, также значительно повысит производительность!
используйте механизм innodb для всех ваших таблиц, в my.cnf установите innodb_buffer_pool_size на 2-3 ГБ оперативной памяти, во время запуска выполните полное сканирование таблицы для всех таблиц [или просто mysqldump -A]. это должно дать вам очень приличную производительность только для чтения, если у вас есть хорошие индексы для всех таблиц.
также, если вы воспользуетесь этим решением, ваш код будет проще - вам не придется заботиться о синхронизации обратно из in -Таблицы ПАМЯТИ обратно в таблицы myisam / на диске.
Снято в темноте, но действительно ли вы сначала испытываете проблемы с производительностью?
Во-вторых, если у вас возникли проблемы с производительностью, вам придется обратить внимание на настройку. Настройте приложение (если вы являетесь разработчиком или имеете особые привилегии для разработчиков), чтобы использовать правильные запросы, чтобы вы не использовали огромные JOIN и т. Д.
Затем посмотрите на архитектуру базы данных. Придумывая глупые обходные пути, вы сможете решить эту проблему позже. Действия, которые вы предпримете, зависят от вашего случая использования. Вы можете рассмотреть возможность вертикального масштабирования мощного сервера, затем поместить его за сервером memcached и создать подчиненный сервер, доступный только для чтения, для таких вещей, как запуск отчетов и резервное копирование.
Не отбирайте оперативную память из базы данных, чтобы попробовать схему, которая подрывает хорошие практики. Существуют блоги для высокопроизводительной настройки базы данных, где можно найти идеи, а в блоге подкастов StackOverflow есть статистика работы этого сайта (MS Stack); относительно интенсивный трафик, но не сложная установка.