Это, безусловно, спорный вопрос, так как многие могут сразу порекомендовать простые вещи, например: Разделить столы! Разделите чтение / запись на конфигурации главный / подчиненный! Увеличьте оперативную память сервера! И так далее .... позвольте мне сначала объяснить проблему:
У меня есть несколько мощный сервер: 8 ГГц, 160 ГБ памяти, 8 ГБ ОЗУ (16 ГБ Flexi RAM), RAID 10, 16 ГБ Flexi-SSD. Запуск mySQL, PHP, Apache, Debian.
Моя текущая база данных состоит примерно из 16 таблиц, одна из которых, в частности, содержит 1,7 ГБ информации с 23 миллионами строк (проиндексированных).
Я запускаю службу, которая требует ежедневного, иногда ежечасного сканирования данных, которые я получаю от третьих лиц, и которая производит от 100 новых строк в минуту до максимум 5000 строк в минуту или около того (редко). Данные извлекаются через поискового робота, получающего их из API, и эти поисковые роботы запускаются автоматически, по расписанию, а иногда и по расписанию, поэтому они требуют большого количества операций записи для мастера.
Когда люди используют сайт, будут доступны обновленные запросы, чтобы показать им их последние аналитические данные, так что это, когда много людей вошло в систему, чрезвычайно тяжелое для чтения (я работал с медленными запросами и пытался уменьшить все с помощью индексов где мог). Я производю эти аналитические данные «на лету» из БД (им не более 24 часов), и они могут содержать до 5 миллионов записей, суммированных на пользователя. Я не думаю, что имеет смысл предварительно отрендерить эти запросы, поскольку мне придется как-то учитывать все срезы / фильтрацию в предварительно отрисованных HTML-файлах ... верно? Или люди так делают?
Теперь, иногда, я получаю предупреждения на свой телефон, авторизуюсь на сервере только для того, чтобы узнать, что mySQL не работает. Я выполню mysqlcheck and repair, что займет до 2 часов или дольше и, наконец, завершится с работающей базой данных. Все запускаю и снова все устраивает. Я никогда не узнаю, почему это происходит, в основном, хотя это случается, когда блог пишет о сайте, а люди просто сходят с ума и атакуют сайт, регистрируясь. Но нет подробного журнала, где он разбился и упал.
Могу ли я сделать что-нибудь, кроме ограничения скорости процесса регистрации (очередь ожидания), чтобы убедиться, что в любом случае MYSQL НЕ БУДЕТ СБОЙ? Могу ли я запускать автоматическое восстановление и оптимизацию на работающем экземпляре примерно раз в час? Я предполагаю, что это блокирует весь доступ к таблицам, что было бы ужасно?
Я действительно поражен этим. Я разделил чтение / запись и теоретически мог бы разделить всех пользователей с доступом для чтения на подчиненные серверы в экземплярах EC2. Но тогда у меня есть проблема с резкими скачками использования, которые резко увеличиваются и уменьшаются, и как только мне понадобится новый экземпляр EC2, мне потребуется передать до 2 ГБ данных для синхронизации подчиненной базы данных ... что никогда не работает через журнал mysql-bin если я решу выключить / загрузить экземпляр EC2 с паузой на несколько дней.
Я был в состоянии идти в ногу со временем, пока не узнал, но даже с EC2 и другими технологиями под рукой я не нахожусь на пределе своего понимания и технических возможностей.
Я хотел бы поделиться ВСЕЙ информацией, необходимой для того, чтобы сделать эту тему / документ полезным на будущее. Поскольку не каждый веб-сайт является средой типа youtube / youporn / instagram / tumblr, я считаю, что для моего типа сайта слишком мало информации (высокая скорость записи / чтения, от 500 до 5 миллионов записей на пользователя, при 3000-10000 пользователей.
Спасибо всем, спрашивайте, и я предоставлю дополнительную информацию. Я хотел бы услышать ваши лучшие практики.
Я думаю, что ваш my.cnf неправильно настроен относительно того, что вы представили в комментарии. Вы, вероятно, «даете» mysql намного больше оперативной памяти, чем доступно вашей системе. Thread_stack = 100M намного больше рекомендованного. Готов поспорить, что OOM-killer просто убивает ваш mysql, чтобы ядро не выходило из памяти.
Вы должны сначала проверить конфигурацию mysql с помощью mysqltuner и настройте конфигурацию mysql, чтобы избежать сбоев сервера.
Запускать REPAIR, ANALYZE, OPZIMIZE, ... в производственной среде на основе cron в отношении ваших больших данных не рекомендуется, но было бы хорошей практикой время от времени очищать таблицы.