Daniel Newman

рекомендую redis, у него на ключик можно поставить время жизни, также есть механизм PUB/SUB, но и все остальное прокатит, в том числе и prostgres и mysql. Также можно использовать elastisearch +logstash для хранения логов.

Если самоцель такого выноса - прекратить влияние дампов на доступность чтения с БД, то, при условии, что ваши таблицы в InnoDB и у вас включён binlog, вы можете снимать копии БД с помощью xtrabackup (innobackupex), не останавливая службу и не прерывая доступ к таблицам.
Изменения, произошедшие с момента старта бекапа, "доедут" из бинлога на завершении процесса.
Снимать копии можно как на тот же сервер, так и стримить их (без использования локального диска) на другой.

Если таблицы в MyISAM, можно настроить SLAVE-сервер и снимать дампы с него, не влияя на доступность основного.

Это практика.

Правда из контекста не совсем ясно - это некие регулярные дампы данных для резервирования, или это ручные дампы для разработчиков, которые они могут спонтанно снять в любое время через phpmyadmin?
Если второе, то это не исправить изменением архитектуры. Для чего dev'ы дампят базу с логами? Почему они не могут задампить только нужные мелковесящие таблицы, или даже ограничиться их структурой, чтобы не задевать другие таблицы?
Если для разработки необходим весь снэпшот базы, я бы сделал его снятие регулярным с xtrabackup и публиковал разработчикам для скачивания по сети из одного конкретного места, чтобы никто больше не подключался к продакшену и не делал никаких дампов с продакшена.

Imho:
1) БД 7 гигов как бы не много. Оно должно дампиться за несколько минут.
2)
- Зачем каждому разработчику актуальный дамп продакшена?
- Зачем это все хостить на боевом сервере?
3) Идея писать логи в основную БД весьма порочна. Поднимите под неё какую нибудь монгу, ну или хотя бы отдельный sql сервер.
4) Идея хранить картинки в базе конечно имеет право на жизнь, но для этого нужны веские аргументы.
Мне кажется вполне можно вынести работу с картинками в отдельный сервис (единый для всех) и хранить это все дело в файловой системе.

Сам там балуюсь в свободное время. С точки зрения фронтенда он не так полезен, т.к. однобоко задействуется язык. Тем не мнее для глубокой проработки алгоритмов он вполне годится и полезен.

Плюс после решения очередной ката, там доступны решения других участников, и встречаются очень любопытные примеры кода, что называется на острие прогресса, и есть смысл не только решать ката, но и изучать код других участников, черпая оттуда вдохновение и опыт.

Функциональщики - будут в тебя кидать тапки
ООПшники - будут радоваться

Минус в том, что если ты городишь обьект только для его передачи в функцию, то ето странно.
Если твой обьект проходит через весь твой код, то - нормально

А так, вероятность породить ошибки на ровном месте, только из-за сомнитльного удобства

Нет никаких минусов, все правильно вы подумали, обычно при четырех параметрах и более используют уже объект, для передачи параметров.

Прототипы First и Second это два разных объекта, хоть и выглядят одинаково "Object {}"
Поэтому метод, добавленный в прототип First, доступен в его экземпляре a и недоступен в экземпляре b Second.

А что мешает триггер повесить в complete ?
или вызвать нужную функцию внутри секции complete?

У меня была та же проблема, с nic.ru пришел ответ:
В связи с особенностями архитектуры системы оказания услуг, исходящие соединения по протоколу SSH с веб-сервера невозможны.

Если Ваш репозиторий поддерживает работу по HTTPS, то Вы сможете им воспользоваться, однако имя пользователя и пароль для подключения к репозиторию следует указывать в URL репозитория, например, так:

https://user:password@repository.com...