Михаил

1. Создайте копию системы через Time Machine.
2. Создайте виртуальную машину используя диск восстановления - Recovery partition (More options... при создании новой виртуальной машины).
3. Восстановите систему на виртуалке (будет предложено в конце установки).

Как раз таки я бы подумал что это не пыль на линзе или около неё, исходя из того что фокус на бесконечности, а эти штуки достаточно резкие, оно бы наверняка не так выглядело.

для репликации бд используйте нативную streaming replication, она довольна проста в освоении.
www.thislinux.org/2014/03/postgresql-streaming-rep...

Repmgr по сути набор скриптов над потоковой репликацией, поэтому с ними можно добиться того же результата.

Best practices следующие:
1. железо стендбая должно быть идентично или лучше чем у мастера, т.к. стендбай может в случае аварии стать мастером и будет грустно если он не потянет нагрузку.
2. обратите внимание на надежность и пропускную способность сети, она должна переваривать те объемы трафика что полетят с мастера на стендбай
3. оттестируйте и составьте инструкции по переключению стендбая в мастер, чтобы в случае аварии не суетиться (оттестировать можно на staging).
4. настройте wal archiving и резервное копирование через basebackup т.к. при потенциальных ошибках оператора/кривой миграции (DROP/TRUNCATE TABLE, DELETE ALL) все изменения улетят на стендбай и он вместе с мастером превратится в тыкву.

Не логичнее ли спросить у саппорта Твиттера?

@evnuh У кого еще и вредные советы. Это буферизация будет заметна только на больших запросах. На простеньких запросах разница будет не заметна. Ответ был дан исходя из задачи. А по вашему можно и mysql захаять и сказать Oracle лучше. Только зачем тратить деньги, ресурсы компьютера, время на работу с mysql. Если нагрузки на базу в этом проекте и не предвидится. Если В итоге сюда полезет табун, то мне кажется его сайт сам по себе не справится с толпой и не поможет ему база данных. От нее будет толку мало если наверху говнокод. Ни кого не хотел обидеть. Просто считаю что нужно не писать велосипеды а бороться с реальными проблемами. Для его задач вполне хватит sqllite. Если будет что то разрастаться, то лучше уже брать готовую cms.

с точки зрения надежности — да, лучше внешний аппаратный рейд-контроллер от какого-нибудь известного вендора. но брать лучше пару — чтобы если один умрет можно было оперативно поднять массив а не ждать пока приедет замена. Программныый в этом плане гибче — винты всегда можно поставить в другую машину и собрать его там.
с точки зрения производительности — разница как правило незаметна — современные процессоры довольно шустро считают.
еще один довод в пользу аппаратного — если один из винтов помирает, то на аппаратном он как правило спокойно вышибается из массива. с программным же возможны варианты — у меня были случаи когда один винт со сгоревшей электроникой вводил ядро в такую задумчивость, что приходилось тушить машинку. т.е. с горячей заменой на аппаратном все гораздо лучше (если контроллер поддерживает и корзины есть)

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

В материнских платах обычно стоит fake-raid, неизвестно как распределяющий данные. В случае если накроется материнская плата или система, восстановить данные будет достаточно проблематично. Я бы выбрал программный. Кроме того не факт, что встроенный рейд фря распознает.