Почитал в википедии о промышленном освоении астероидов. Все классно так расписано, цыфры приведены, экономические выгоды. Вот мне интересно, где можно будет использоавать металы добытые на астероидах? В Чернобыле? Фукусиме? Металл с астероидов будет радиоактивным. Возможно, конечно, придумают способ дешевой деактивации добытых металов. Пока что выглядит как самопиар перед инветорами.
при большом количестве серверов = большом объеме даных для резервного копирования, существенно увеличивается время, необходимое на бэкап.
Я находился в ситуации, когда бэкапы всех серверов LAMP (linux-apache-mysql) выполнялись около 8-ми часов. Из-за большого размера баз данных и вэб контента.
Для решения даной проблемы было решено переводить все сервера на ежедневный диференциальный бэкап. Полные бэкапы делать только в пятницу, субботу и воскресение для отдельных 3-х груп серверов. Как не странно времени это не сильно сэкономило. (~1,5 часа).
Спасло положение сжатие баз данных вызовом отдельного скрипта:
#!/bin/bash
root_pass='mysql_root_password'
databases=`echo «show databases»|mysql -u root -p$root_pass|grep -v "^D" | grep -v «information_schema»`
if [ "$1" == «full» ]; then
echo Starting full backup
for FLS in ${databases}
do
/usr/bin/mysqldump --force --single-transaction --opt -u root -p$root_pass ${FLS} |/bin/bzip2 -c -9 > /var/lib/mysql/backup/${FLS}.full.mysql.bz2
done
fi
if [ "$1" == «clean» ]; then
/bin/rm /var/lib/mysql/backup/*
fi
размещается он на клиент-сервере в папке /etc/bacula/scripts/. Устанавливаются права на выполнение (chmod +x).
Также нужно создать папку куда будут падать сжатые базы: mkdir /var/lib/mysql/backup
На сервере бакулы нужно создать отдельную джобу для бэкапа баз даных, где и указать использование скрипта:
JobDefs {
Name = «DabasesBackupJobName»
Type = Backup
Level = Full
ClientRunBeforeJob = "/etc/bacula/scripts/mysqlbackup_script_name 'full'"
ClientRunAfterJob = "/etc/bacula/scripts/mysqlbackup_script_name 'clean'"
}
На этом этапе пару сотен гигабайт предварительно сжатых и отобраных даных залетают на сервер бакулы на 2-3 часа.
Еще лучше сделать крон задание и запускать этот скрипт в одно и то же время на всех серверах, а дампы забирать вместе с другими файлами. Просто нужно включить /var/lib/mysql/backup в соответсвующий FileSet (если вы делаете бэкап выбраных папок, а не полный бэкап всего сервера. + ~1 час экономии.
можно использовать и eAccelerator и APC.
Еще раз напоминаю: я не писал статью по оптимизации сервера!!!
То же самое касается настроек БД. Каждый разработчик в праве сам решать какую БД ему использовать. И это уже дело хостера как оптимизировать движок БД.
Доки nginxa я читал и довольно много. Использую его повсеместно, в виду архитектуры проектов не удается полностью отказаться от апача. Но это лирика.
На счет haproxy — специально его сюда втулил для полноты схемы. Согласен достаточно nginx+varnish+php-fpm. При этом логировать ip клиентов будет легче — он не будет теряться в хэдэрах x-forvarded-for при прохождении всего пути пакета.
Можно и от nginxa отказаться в пользу haproxy, поскольку последнее показывает выше производительность по сравнению с nginxoм при высоких нагрузках (на просторах интернета есть достаточно сравнительных статей).
Можно и от варниша отказаться. И кэшировать все nginxom, убирая неугодные Cookie и хэдэры с помощью дополнительного модуля сторонних разработчиков.
Можно что угодно сделать. Сложите мысли воедино и изложите :-)
Я не занимаюсь пропагандой какой-либо схемы. Просто описал, максимально полно, что так тоже можно сделать. И оно даже должно работать. При чем каждое звено в цепи взвешено. Их можно комбинировать, удалять те, которые не нравятся, заменять более удобными.
Вы абсолютно правы. Умолчал. Репликация и failover — дело рук каждого отдельно. Для отказоустойчивости понадобится еще по одному серверу каждого типа. Дальше чем хотите — drbd, mysql replication, rsync, etc. Ну и heartbeat конечно. Или какой-то самописный велосипед.
Я не хотел делать сильно большую статью, поэтому не вдавался в подробности failovera.
мой знакомый на фотке, кажется. Игорь зовут.
Я находился в ситуации, когда бэкапы всех серверов LAMP (linux-apache-mysql) выполнялись около 8-ми часов. Из-за большого размера баз данных и вэб контента.
Для решения даной проблемы было решено переводить все сервера на ежедневный диференциальный бэкап. Полные бэкапы делать только в пятницу, субботу и воскресение для отдельных 3-х груп серверов. Как не странно времени это не сильно сэкономило. (~1,5 часа).
Спасло положение сжатие баз данных вызовом отдельного скрипта:
#!/bin/bash
root_pass='mysql_root_password'
databases=`echo «show databases»|mysql -u root -p$root_pass|grep -v "^D" | grep -v «information_schema»`
if [ "$1" == «full» ]; then
echo Starting full backup
for FLS in ${databases}
do
/usr/bin/mysqldump --force --single-transaction --opt -u root -p$root_pass ${FLS} |/bin/bzip2 -c -9 > /var/lib/mysql/backup/${FLS}.full.mysql.bz2
done
fi
if [ "$1" == «clean» ]; then
/bin/rm /var/lib/mysql/backup/*
fi
размещается он на клиент-сервере в папке /etc/bacula/scripts/. Устанавливаются права на выполнение (chmod +x).
Также нужно создать папку куда будут падать сжатые базы: mkdir /var/lib/mysql/backup
На сервере бакулы нужно создать отдельную джобу для бэкапа баз даных, где и указать использование скрипта:
JobDefs {
Name = «DabasesBackupJobName»
Type = Backup
Level = Full
ClientRunBeforeJob = "/etc/bacula/scripts/mysqlbackup_script_name 'full'"
ClientRunAfterJob = "/etc/bacula/scripts/mysqlbackup_script_name 'clean'"
}
На этом этапе пару сотен гигабайт предварительно сжатых и отобраных даных залетают на сервер бакулы на 2-3 часа.
Еще лучше сделать крон задание и запускать этот скрипт в одно и то же время на всех серверах, а дампы забирать вместе с другими файлами. Просто нужно включить /var/lib/mysql/backup в соответсвующий FileSet (если вы делаете бэкап выбраных папок, а не полный бэкап всего сервера. + ~1 час экономии.
Это статья не имела такой цели.
Еще раз напоминаю: я не писал статью по оптимизации сервера!!!
То же самое касается настроек БД. Каждый разработчик в праве сам решать какую БД ему использовать. И это уже дело хостера как оптимизировать движок БД.
На счет haproxy — специально его сюда втулил для полноты схемы. Согласен достаточно nginx+varnish+php-fpm. При этом логировать ip клиентов будет легче — он не будет теряться в хэдэрах x-forvarded-for при прохождении всего пути пакета.
Можно и от nginxa отказаться в пользу haproxy, поскольку последнее показывает выше производительность по сравнению с nginxoм при высоких нагрузках (на просторах интернета есть достаточно сравнительных статей).
Можно и от варниша отказаться. И кэшировать все nginxom, убирая неугодные Cookie и хэдэры с помощью дополнительного модуля сторонних разработчиков.
Можно что угодно сделать. Сложите мысли воедино и изложите :-)
Я не занимаюсь пропагандой какой-либо схемы. Просто описал, максимально полно, что так тоже можно сделать. И оно даже должно работать. При чем каждое звено в цепи взвешено. Их можно комбинировать, удалять те, которые не нравятся, заменять более удобными.
Я не хотел делать сильно большую статью, поэтому не вдавался в подробности failovera.