Про MySQL. Зависит от сложности и размера БД, но я бы посоветовал обратить внимание на следующее:
В приведенном варианте восстановить БД отдельно взятого клиента так просто не получится. Лучше бекапить каждую БД отдельно.
Если у кого-то были процедуры, то их в бекапе не окажется.
mysqldump делает дамп в текстовом виде. Если БД большая, то это и долго, и много места занимает. Потому лучше вывод mysqldump сразу передавать в gzip, минуя промежуточный этап записи на диск.
Можно легко поймать ситуацию когда целостность данных в дампе нарушится. Потому хорошо добавить ключ --single-transaction.
Посмотреть percona xtrabackup. В этом случае получится делать бекап всех/некоторых БД быстро и не мешая пользователям, и с гарантированой целостностью.
Сразу скажу, я не очень разбираюсь во внутренностях Zookeeper.
По идее в кластере zookeeper-ам надо вписывать в конфиг уникальное значение zoo_id (0-255).
Плагин берет указанное значение (node_zoo_id), либо в случае если оно не указано — номер хоста из группы «zookeeper».
Одни со временем становятся старше и умнее, другие — просто старше.
«Потому что я так сказал», «потому что я лучше знаю» и прочие — не аргумент. Это следствие некого опыта, проб и ошибок. И надо докопаться до причины.
Иногда таки приходится делать плохо если «сделать хорошо» просто нет возможности (hotfix для упавшего продакшена вместо переписывания библиотеки спровоцировавшей падение, ...).
Если всё действительно упирается в заросшего мхом и непробиваемого для здравого смысла руководителя то есть же вариант сменить место работы.
И я не поверю что программисту с головой на плечах и горящими глазками тяжело найти работу.
Хотя легко поверю что это будет чертовски тяжело для замшелого программера не желающего учиться чему-то новому.
Что бы ни говорил старший (и вероятно более опытный) сотрудник — это аж никак не отменяет необходимости думать своей головой и как минимум понимать почему посоветовали сделать именно так.
Вы знаете, это звучит как «мы вот как-то так сделали, а потом сделаем лучше». В этот же минутный трейлер можно было а) не добавлять явную последовательность, а сделать набор разных боевых ситуаций
Едет «АСК» по дороге, и тут СОВЕРШЕННО НЕОЖИДАННО сзади него обнаружился «Зверь». Метрах в 100. В пустыне. Иначе почему бы башня не была развернута в его сторону с самого начала?
И вот мы видим как артиллерия стоит в чистом поле. Где патрули и прочие наблюдательные посты? К ним через пустыню несутся шумно перестреливаясь как миниум 2 машины. По пустыне. Где их видно еще на горизонте. И по радио никто ничего не слышал, и глазками не видел. Не говоря уже о радарах. Но вот в ста метрах от артиллерии вдруг радиосвязь появилась, и внезапно «тролли» внезапно обрели способность видеть.
Далее. Подъехал «Барьер» дабы отремонтировать подбитую машину. Еще одна машина у него в прикрытии. Тут мы видим что за «зверем» ехало еще 2 машины. И тут они рванулись в чистое поле гоняться за шустриком. Перед артилерийскими установками. И это вместо того чтоб уничтожить стоящие на дороге цели.
В общем, выглядит красиво. Но пока-что не более того.
Большой минус — история хранится с самого первого бекапа. И если в него попадет что-то лишнее и большого размера — оно там так и останется если не транкейтить git-репо периодически.
Тут есть проблема. Когда кодишь, ты видишь расположение клавиш которые нажимаешь. Ок, для слепого метода набора — ощущаешь. Потому просто в перчатках позиционировать руки в воздухе ни на что не опираясь будет очень затруднительно.
Потому требуется комбинация из очков/шлема/etc с дополненой реальностью, чтобы сквозь обычные прозрачные очки было видно клавиатуру/… в воздухе — дабы сопостовлять положение рук с положением объектов и сразу же видеть реакцию системы на «ввод».
А почему бы вместо того чтоб пускать апач от админа не взять apache2-itk в котором только этот вхост пустить из-под админа? Либо же вообще — cgi-скрипт на котором стоит setuid.
Если думать об этом заранее, то можно написать приложение так, чтобы создание API занимало минут 5.
Не могу сказать как в ZF, а в Rails используя RESTful routes можно уже облегчить себе жизнь, и данные запрашивать в XML/JSON/… Для простых случаев этого более чем достаточно.
XML-RPC/SOAP/… также никто не отменял для более тяжелых случаев.
Производительность IDE-дисков у меня была просто чудовищно малой. Подключение дисков как scsi эту проблему решало, но при активном использовании ядро раз в дня два впадало в панику. Обычный LAMP-стек на ubuntu 10.04 server x86_64.
Про MySQL. Зависит от сложности и размера БД, но я бы посоветовал обратить внимание на следующее:
--single-transaction
.По идее в кластере zookeeper-ам надо вписывать в конфиг уникальное значение zoo_id (0-255).
Плагин берет указанное значение (node_zoo_id), либо в случае если оно не указано — номер хоста из группы «zookeeper».
И нет, не может если:
1. в репозитории хранится как Gemfile, так и сгенерированный Gemfile.lock
2. и если выполняется все через bundle exec
«Потому что я так сказал», «потому что я лучше знаю» и прочие — не аргумент. Это следствие некого опыта, проб и ошибок. И надо докопаться до причины.
Иногда таки приходится делать плохо если «сделать хорошо» просто нет возможности (hotfix для упавшего продакшена вместо переписывания библиотеки спровоцировавшей падение, ...).
Если всё действительно упирается в заросшего мхом и непробиваемого для здравого смысла руководителя то есть же вариант сменить место работы.
И я не поверю что программисту с головой на плечах и горящими глазками тяжело найти работу.
Хотя легко поверю что это будет чертовски тяжело для замшелого программера не желающего учиться чему-то новому.
б) таки добавить 10-20 секунд чтобы закрыть явные нестыковки
Едет «АСК» по дороге, и тут СОВЕРШЕННО НЕОЖИДАННО сзади него обнаружился «Зверь». Метрах в 100. В пустыне. Иначе почему бы башня не была развернута в его сторону с самого начала?
И вот мы видим как артиллерия стоит в чистом поле. Где патрули и прочие наблюдательные посты? К ним через пустыню несутся шумно перестреливаясь как миниум 2 машины. По пустыне. Где их видно еще на горизонте. И по радио никто ничего не слышал, и глазками не видел. Не говоря уже о радарах. Но вот в ста метрах от артиллерии вдруг радиосвязь появилась, и внезапно «тролли» внезапно обрели способность видеть.
Далее. Подъехал «Барьер» дабы отремонтировать подбитую машину. Еще одна машина у него в прикрытии. Тут мы видим что за «зверем» ехало еще 2 машины. И тут они рванулись в чистое поле гоняться за шустриком. Перед артилерийскими установками. И это вместо того чтоб уничтожить стоящие на дороге цели.
В общем, выглядит красиво. Но пока-что не более того.
Потому требуется комбинация из очков/шлема/etc с дополненой реальностью, чтобы сквозь обычные прозрачные очки было видно клавиатуру/… в воздухе — дабы сопостовлять положение рук с положением объектов и сразу же видеть реакцию системы на «ввод».
Не могу сказать как в ZF, а в Rails используя RESTful routes можно уже облегчить себе жизнь, и данные запрашивать в XML/JSON/… Для простых случаев этого более чем достаточно.
XML-RPC/SOAP/… также никто не отменял для более тяжелых случаев.
SCSI и есть синтетический.
Еще плохо что загрузочный диск может быть только IDE.