Minha aplicação vai rodar também em uma maquina Ubuntu Server 11.04, com o PHP5.3, vamos configurar isso tudo de uma vez!

Instalação do PHP

Vamos precisar instalar alguns pacotes para tudo funcionar, comece instalando o mongodb, da mesma forma que foi feito no item “instalação” do post anterior, depois vamos precisar de mais alguns pacotes:

sudo aptitude install libapache2-mod-php5 php-apc php-pear php5-dev build-essential

• libapache2-mod-php5: Instala o apache2, o php5 e claro, o modulo do apache
• php-apc: Modulo de cache de opcode do php, para performance =)
• php-pear: Vamos precisar paixar o modulo do mongo para o php
• php5-dev e build-essential: Para que o modulo possa ser compilado

Depois de tudo instalado, vamos configurar o php para poder acessar o mongo e reiniciar o apache

sudo pecl install mongo
sudo sh -c 'echo "extension=mongo.so" > /etc/php5/apache2/conf.d/mongodb.ini'
sudo service apache2 restart

Configuração do Arbitro

Como disse no post anterior, o Arbitro é uma instancia do mongo que existe apenas para decidir qual dos membros do replicaSet será o novo Master caso algum venha a falhar de alguma forma.

Primeiro edite todos os arquivos /etc/hosts das maquinas do replicaSet e adicione o IP do arbitro (que no meu caso é o IP do servidor de aplicação) e também adicione estas entradas no servidor de aplicação

192.168.0.100      arquivo1a 
192.168.0.101      arquivo1b
192.168.0.102      arquivo1bkp
192.168.0.99       arquivo1arbiter

Depois disso, faça login no servidor que é o seu nó Master do replicaSet, verifique quem é acessando:

http://192.168.0.101:28017/_replSet

e vamos configurar, acesse a administração do mongo:

mongo admin

e adicione o arbitro ao replicaSet:

rs.addArb("arquivo1arbiter")

feito isso, de ctrl+c e confira o status do seu replicaSet (http://192.168.0.101:28017/_replSet):

Com isso nosso replicaSet está pronto para receber nossa aplicação, faça testes desligando o processo de seus clientes e veja como um outro assume, neste caso, se o servidor arquivo1a e arquivo1b caírem, a aplicação para, mas é muito simples adicionar novos nós para aumentar essa segurança,  o mínimo para um replicaSet de produção são 3 instâncias para armazenamento, uma de backup e um arbitro.

até a próxima parte.

Depois de olhar algumas soluções existentes como MogileFS, Cassandra, entre outros, eu gostei bastante do GridFS do MongoDB, pela simplicidade de configuração e principalmente pelo sistema de eleição de um novo servidor mestre caso o ativo venha a falhar em um determinado replicaSet.

Minha configuração inicial dessa estrutura consiste em dois servidores de Storage (Ubuntu Server 11.04 64bits rodando em VMs vmware em discos diferentes) e uma terceira maquina simples e remota que será um backup onde será configurado meu primeiro ReplicaSet. No servidor de aplicação vou ter o MongoDB rodando como arbitro (sem armazenar dados) apenas para determinar qual o servidor é o mestre caso algum venha a falhar.

Instalação:

Considerando que nos servidores foi instalado o ubuntu server, sem nada, vamos a configuração:

primeiro vamos adicionar a linha na configuração do APT para podermos baixar o pacote oficial do MongoDB, mantido pela 10-gen, crie o arquivo: /etc/apt/sources.list.d/mongo.list e adicione a linha:

deb http://downloads-distro.mongodb.org/repo/ubuntu-upstart dist 10gen

depois de salvar o arquivo, adicione a chave do repositorio:

sudo apt-key adv --keyserver keyserver.ubuntu.com --recv 7F0CEB10

e finalmente instale o mongodb:

sudo aptitude update
sudo aptitude install mongodb-10gen

repita este processo em todas as maquinas de seu replicaSet.

Configuração do MongoDB

Primeiro vamos criar a pasta de armazenamento dos dados e definir as permissões:

sudo mkdir /dados
sudo chown mongodb:mongodb /dados/
sudo chmod 700 mongodb -Rf

Em todos os servidores vamos editar a configuração do MongoDB em /etc/mongodb.conf, aqui ficou assim:

dbpath=/dados/
logpath=/var/log/mongodb/mongodb.log
logappend=true
replSet = arquivo1
rest=true

* o parâmetro rest, faz com o que o servidor crie uma página para monitoramento dos status.

Depois de configurar todos os membros do replicaSet, reinicie o processo em todas as maquinas:

sudo service mongodb restart

Agora temos os servidores prontos para configurar a parte mais simples, o replicaset

Configuração do ReplicaSet

Para facilitar, configure nomes para seus membros do replicaSet no seu servidor de DNS interno ou, edite o arquivo /etc/hosts e adicione as maquinas que serão membro do replicaSet:

192.168.0.100      arquivo1a 
192.168.0.101      arquivo1b
192.168.0.102      arquivo1bkp

* Ajuste os IPs de acordo com sua rede.

Agora, em um servidor qualquer, acesse o console de administração do Mongo:

mongo admin

e crie a configuração do replicaSet:

conf = { _id : 'arquivo1',                    
... members : [
... {_id: 0, host: 'arquivo1a'}, 
... {_id: 1, host: 'arquivo1b'},
... {_id: 2, host: 'arquivo1bkp', priority: 0}
... ]}

* Note que o servidor de backup tem prioridade zero, isto faz com que este servidor nunca seja eleito como servidor Mestre.
confira se está tudo ok:

{
	"_id" : "arquivo1",
	"members" : [
		{
			"_id" : 0,
			"host" : "arquivo1a"
		},
		{
			"_id" : 1,
			"host" : "arquivo1b"
		},
		{
			"_id" : 2,
			"host" : "arquivo1bkp",
			"priority" : 0
		}
	]
}

se estiver ok, ainda no console do Mongo, inicialize o replicaset:

rs.initiate(conf)

em 10 segundos o seu replicaSet deverá estar rodando e pronto para receber dados, veja como está pelo navegador, acessando:

http://192.168.0.100:28017/_replSet

Você verá uma tela com o status de todos os membros do replicaSet:

Bom, é isso, no próximo post vou explicar como configurar o php e efetivamente armazenar arquivos no GridFS, Abraços

wget http://download.macromedia.com/pub/labs/flashplatformruntimes/flashplayer11/flashplayer11_b1_install_lin_64_071311.tar.gz
tar -zxvf flashplayer11_b1_install_lin_64_071311.tar.gz
sudo cp usr / -Rfv
sudo cp libflashplayer.so /usr/lib/flashplugin-installer/ /etc/alternatives/firefox-flashplugin

Depois é só reiniciar seu firefox e conseguir ver aquelas apresentações legais no slideshare.

Depois disso foi correr para a criação do script para ler o HTML e retornar um objeto contendo as informações da temperatura no momento, segue o código escrito em php:

function loadTemp($cidade='Palmas-TO'){
	// variavel para dados de retorno
	$ret = array('url' => "http://tempoagora.uol.com.br/previsaodotempo.html/brasil/$cidade/");
 
	// carrega o html do tempoagora
	$html = file_get_contents($ret['url']);
 
	// Pegamos apenas a parte que interessa do html
	$iniflag = '<!-- Insere dados Atuais de AeroPortos ou Est. Meteorologica -->';
	$fimflag = '<!-- FIM Insere dados Atuais de AeroPortos ou Est. Meteorologica -->';
	$ini = strrpos($html, $iniflag ) + strlen($iniflag);
	$fim = strpos($html, $fimflag, $ini);
	$html = substr($html, $ini, ($fim-$ini));
 
	// pegamos a url do icone
	preg_match('@<img src="/(imagens/icones/[a-zA-Z\-]+.gif)"@', $html, $mat);
	$ret['icone'] = 'http://tempoagora.uol.com.br/' . $mat[1];
 
	// Limpa o código html
	$content = strip_tags($html);
	$content = str_replace('&nbsp;', ' ', $content);
 
	// quebra o que sobrou em um vetor
	$content = explode("\n", $content);
 
	// limpa espaços e linhas em branco
	foreach ($content as $k => &$v){
		$v = trim($v);
		if ($v==='') unset($content[$k]);
	}
 
	// pega horário da verificação
	$lin = array_shift($content);
	preg_match('@[0-9]{1,2}:[0-9]{1,2}@', $lin, $mat);
	$ret['verificado']  = $mat[0];
 
	// pega insidência de nuvens
	$ret['nuvens'] = array_shift($content);
 
	// define nomes melhores para as próximas propriedades
	$keys = array('temperatura', 'sensacao', 'vento', 
			'pressao', 'umidade', 'visibilidade');
 
	// reseta as chaves do vetor
	$content = array_unique($content);
 
	// percorre chaves impares e aplica as propriedades definidas acima
	for ($x=1; $x<=11; $x=$x+2){
		$ret[array_shift($keys)] = $content[$x];
	}
 
	// retorna os dados como um objeto
	return (object)$ret;
}

Analisando o site deles, notei que a temperatura é atualizada de hora em hora, então a melhor forma de utilizar essa solução é utilizando o crontab, que executa a cada hora, eu escolhi executar no quinto minuto de cada hora cheia (5:05, 6:05, etc).

segue o código php que o crontab executa:

require 'loadTemp.php';
// define nome do arquivo de cache
$cache_file = sys_get_temp_dir() . '/temp';
 
// carrega a temperatura
$temp = loadTemp();
 
// salva em cache
file_put_contents($cache_file, serialize($temp));

E para exibir no sistema eu fiz uma funçãozinha:

function temp(){
	$cache_file = sys_get_temp_dir() . '/temp';
	// se o cache existe, retorna o objeto
	if (file_exists($cache_file)) 
		return unserialize(file_get_contents($cache_file));
 
	// senão cria o cache e retorna =)
	$temp = loadTemp();
	file_put_contents($cache_file, serialize($temp));
	return $temp;
}

depois, no local específico, ficou algo mais ou menos assim:

<?php $temp = temp() ?>
<img src="<?php echo $temp->icone ?>" alt="<?php echo $temp->nuvens ?>" />
<span><?php echo $temp->temperatura ?> (<a rel="external" href="<?php echo $temp->url ?>">saiba mais</a>)</span>

Minha forma de pagar por esse uso é manter um link para o Tempoagora, o que é bastante interessante, pois meu visitante pode querer obter mais informações

É isso ai, abraço a todos

Vamos direto ao ponto, confira o exemplo:

http://ferrari.eti.br/correios/samples/class.php

E para deixar a brincadeira mais divertida, fiz também um webservice com suporte a Json (padrão), phpserialize, XML e um modo dump, para visualização:

http://ferrari.eti.br/correios/webservice/?q=PB151832535BR
http://ferrari.eti.br/correios/webservice/?q=PB151832535BR&f=dump
http://ferrari.eti.br/correios/webservice/?q=PB151832535BR&f=serial
http://ferrari.eti.br/correios/webservice/?q=PB151832535BR&f=xml
e claro, para quem usa Ajax:
http://ferrari.eti.br/correios/webservice/?q=PB151832535BR&callback=minhaFuncJs

Disponibilizei tanto a classe quanto o código do webservice (que tem suporte a caching!) “de grátis” e com licença BSD no github:

http://github.com/caferrari/correios/

*UPDATE* Adicionado um gerador de RSS, assim é possível usar o proprio agregador para fazer o tracking!

http://ferrari.eti.br/correios/rss/?PB151832535BR

e em homenagem aos atendentes de telemarketing: Estarei esperando forks e colaborações para a classe, além de comentários!.

Até a próxima.

PHP-FPM: é um gerenciador de processos CGI do php, similar ao Phpcgi, porém com várias vantagens como:

• Gerenciador de Processos muito eficiente, com capacidade de parar e iniciar seus deamons caso necessário
• Possibilidade de Iniciar processos com usuários diferentes e com arquivos php.ini diferentes
• Uploads otimizados
• Capacidade de reinicializar processos caso ocorra algum problema
• Escalabilidade de processos, ele pode criar mais processos de acordo com a demanda
• e muito mais.

XCache: é um gerenciador de cache, que armazena os scripts php em opcode para uso futuro, é extremamente rápido e muito usado no mundo em servidores com alta demanda.

Nginx: Conheci este webserver lendo o blog da boo-box, ele é um Servidor web e proxy reverso extremamente veloz e que vem ganhando mercado nos últimos meses devido a sua facilidade de uso e capacidade de carga.

Para agilizar a configuração, vamos usar alguns pacotes (php5.3, php-fpm) pré compilados e mantidos www.dotdeb.org. os testes que eu realzei usando estes pacotes tiveram um ganho de performance enorme.

Instalação:

Vamos começar adicionado os repositórios do dotdeb no /etc/apt/sources.list:

deb http://php53.dotdeb.org stable all
deb-src http://php53.dotdeb.org stable all

Vamos instalar os pacotes e algumas dependências para o nginx:

aptitude update
aptitude install php5-fpm php5-xcache php5-gd php5-curl \
php5-mysql php5-pgsql libssl-dev libpcre3-dev build-essential -y

Agora temos o php instalado, vamos compilar o nginx:

cd
mkdir src
cd src
wget http://nginx.org/download/nginx-0.7.64.tar.gz
tar -zxvf nginx-0.7.64.tar.gz
cd nginx-0.7.64
./configure --prefix=/usr/local/nginx --user=www-data --group=www-data \
    --without-mail_pop3_module --without-mail_imap_module \
    --without-mail_smtp_module --with-http_stub_status_module \
    --with-http_ssl_module --http-log-path=/var/log/nginx/access.log \
    --conf-path=/etc/nginx/nginx.conf  --pid-path=/var/run/nginx.pid
make
make install

Se tudo ocorreu bem, você já tem o nginx instalado, vamos apenas coloca-lo para inicializar automáticamente, crie o arquivo /etc/init.d/nginx e coloque o conteúdo:

#! /bin/sh
 
### BEGIN INIT INFO
# Provides:          nginx
# Required-Start:    $all
# Required-Stop:     $all
# Default-Start:     2 3 4 5
# Default-Stop:      0 1 6
# Short-Description: starts the nginx web server
# Description:       starts nginx using start-stop-daemon
### END INIT INFO
 
PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin:/usr/local
DAEMON=/usr/local/nginx/sbin/nginx
NAME=nginx
DESC=nginx
 
test -x $DAEMON || exit 0
 
# Include nginx defaults if available
if [ -f /etc/default/nginx ] ; then
        . /etc/default/nginx
fi
 
set -e
 
case "$1" in
  start)
        echo -n "Starting $DESC: "
        start-stop-daemon --start --quiet --pidfile /var/run/$NAME.pid \
                --exec $DAEMON -- $DAEMON_OPTS || true
        echo "$NAME."
        ;;
  stop)
        echo -n "Stopping $DESC: "
        start-stop-daemon --stop --quiet --pidfile /var/run/$NAME.pid \
                --exec $DAEMON || true
        echo "$NAME."
        ;;
  restart|force-reload)
        echo -n "Restarting $DESC: "
        start-stop-daemon --stop --quiet --pidfile \
                /var/run/$NAME.pid --exec $DAEMON || true
        sleep 1
        start-stop-daemon --start --quiet --pidfile \
                /var/run/$NAME.pid --exec $DAEMON -- $DAEMON_OPTS || true
        echo "$NAME."
        ;;
  reload)
        echo -n "Reloading $DESC configuration: "
        start-stop-daemon --stop --signal HUP --quiet --pidfile /var/run/$NAME.pid \
            --exec $DAEMON || true
        echo "$NAME."
        ;;
  configtest)
        echo -n "Testing $DESC configuration: "
        if nginx -t > /dev/null >&1
        then
          echo "$NAME."
        else
          exit $?
        fi
        ;;
  *)
        echo "Usage: $NAME {start|stop|restart|reload|force-reload|configtest}" >&2
        exit 1
        ;;
esac
 
exit 0

depois vamos torna-lo executável e atualizar o rc.d:

chmod +x /etc/init.d/nginx
update-rc.d nginx defaults

Com isso o processo de instalação está concluído, vamos configurar!

Configuração do XCache

Coloque a seguinte configuração no arquivo /etc/php5/fpm/conf.d/xcache.ini:

; configuration for php xcache module
extension=xcache.so
 
[xcache.admin]
xcache.admin.user = "secom"
; xcache.admin.pass = md5($your_password)
xcache.admin.pass = ""
[xcache]
; ini only settings, all the values here is default unless explained
; select low level shm/allocator scheme implemenation
xcache.shm_scheme =        "mmap"
; to disable: xcache.size=0
; to enable : xcache.size=64M etc (any size > 0) and your system mmap allows
xcache.size  =                64M
; set to cpu count (cat /proc/cpuinfo |grep -c processor)
xcache.count =                 1
; just a hash hints, you can always store count(items) > slots
xcache.slots =                8K
; ttl of the cache item, 0=forever
xcache.ttl   =                 0
; interval of gc scanning expired items, 0=no scan, other values is in seconds
xcache.gc_interval =           0
; same as aboves but for variable cache
xcache.var_size  =            64M
xcache.var_count =             1
xcache.var_slots =            8K
; default ttl
xcache.var_ttl   =             0
xcache.var_maxttl   =          0
xcache.var_gc_interval =     300
xcache.test =                Off
; N/A for /dev/zero
xcache.readonly_protection = Off
; for *nix, xcache.mmap_path is a file path, not directory.
; Use something like "/tmp/xcache" if you want to turn on ReadonlyProtection
; 2 group of php won't share the same /tmp/xcache
; for win32, xcache.mmap_path=anonymous map name, not file path
xcache.mmap_path =    "/dev/zero"
 
; leave it blank(disabled) or "/tmp/phpcore/"
; make sure it's writable by php (without checking open_basedir)
xcache.coredump_directory =   ""
; per request settings
xcache.cacher =               On
xcache.stat   =               On
xcache.optimizer =            On
[xcache.coverager]
; per request settings
; enable coverage data collecting for xcache.coveragedump_directory and xcache_coverager_start/stop/get/clean() functions (will hurt executing performance)
xcache.coverager =          Off
; ini only settings
; make sure it's readable (care open_basedir) by coverage viewer script
; requires xcache.coverager=On
xcache.coveragedump_directory = ""

Configuração do Nginx

Edite o arquivo em /etc/nginx/nginx.conf:

user  www-data;
 
#Coloque quantos processos simultaneos, o ideal é um para cada nucleo do sistema:
worker_processes  4;
 
error_log  /var/log/nginx/error.log;
 
events {
    # numero de conexões simultaneas por worker
    worker_connections  1024;
}
 
http {
    include       mime.types;
    default_type  application/octet-stream;
 
    access_log  /var/log/nginx/access.log;
    sendfile        on;
    # isso é interessante, dá um ganho enorme na navegação, e o nginx aguenta tranquilamente
    keepalive_timeout  60;
    tcp_nodelay        on;
 
    ## Compressão
    gzip on;
    gzip_http_version 1.0;
    gzip_comp_level 2;
    gzip_proxied any;
    gzip_min_length  1100;
    gzip_buffers 16 8k;
    # mime types para zipar e adicionar header de cache
    gzip_types text/plain text/css application/x-javascript text/xml application/xml application/xml+rss text/javascript image/gif image/jpeg image/png;
    # Desabilita compressão em algumas versões do IE6
    gzip_disable "MSIE [1-6].(?!.*SV1)";
    # Impede que servidores proxy mandem versões em gzip do arquivo para os IE6
    gzip_vary on;
 
    server {
	root  /var/www/;
	server_name     localhost;
	listen          80;
	location / {
		index  index.php index.html index.htm;
	}
 
	#error_page  404  /404.html;
	# redirect server error pages to the static page /50x.html
	error_page   500 502 503 504  /50x.html;
	location = /50x.html {
		root   /var/www/nginx-default;
	}
 
	# Joga requisições para arquivos .php para o php-fpm
	location ~ \.php$ {
		fastcgi_pass   127.0.0.1:9000;
		fastcgi_index  index.php;
		include fastcgi_params;
        	fastcgi_param SCRIPT_FILENAME /var/www/$fastcgi_script_name;
        	fastcgi_param SERVER_NAME $http_host;
        	fastcgi_ignore_client_abort on;
	}
    }
}

Configuração do php-fpm

Edite o arquivo: /etc/php5/fpm/php5-fpm.conf e faça os ajustes que você achar interessante, aqui eu só aumento os max_childrens (Numero de clientes CGI) de 5 para 50, esta configuração depende do seu hardware.

Configuração do Logrotate

Vamos configurar agora o logrotate para não enchermos os discos com logs do nginx, edite o arquivo /etc/logrotate.d/nginx:

/var/log/nginx/*.log {
        daily
        missingok
        rotate 7
        compress
        delaycompress
        notifempty
        create 640 root adm
        sharedscripts
        postrotate
                [ ! -f /var/run/nginx.pid ] || kill -USR1 `cat /var/run/nginx.p$
        endscript
}

Finalizando

Agora que está tudo configurado, vamos reinicalizar os serviços:

/etc/init.d/php5-fpm restart
/etc/init.d/nginx restart

crie um arquivo /var/www/index.php e vamos testar o php:

 
e acesse: http://ip_do_servidor/

A GVT é conhecida como a melhor (realmente muito melhor) operadora de telefônia, que nasceu e atua no Brasil, e ela é melhor em todos os aspectos (atendimento, preço, qualidade de serviço e qualidade de banda larga) enquanto a Telefônica compete com a Oi pelo maior numero de clientes insatisfeitos.

A Vivendi é uma empresa francesa que atua no setor de mídia e comunicação com atividades na música, televisão, cinema, editoração, telecomunicações e Internet. (por: Wikipedia)

Areas de atuação da Vivendi

Bom, mas o que isso significa…

Vamos considerar os seguintes pontos:

• Governo investindo em inclusão digital
• Qualidade dos serviços e atendimento da GVT
• O know-how em mídias e o dinheiro da Vivendi

E juntamos isso com o fato de que a mídia da forma que conhecemos está definhando devido a Internet (RSS, Twitter, Orkut, Facebook, etc).

Com apenas isso já é possível se concluir o óbvio. A Vivendi está vindo para, além de nos prover acesso a internet com qualidade e chutar a Oi e Telefônica de vez, nos prover um serviço que pode em pouco tempo engolir também a nossa TV Digital. Ela vem para criar aqui um sistema de IPTV

Se pararmos para analisar, a TV Digital do mundo todo irá evoluir para IPTV, pois, todas as qualidades da TV Digital (FullHD, Som Surround e Interatividade) podem ser superadas pela Internet.

Daí pega outro ponto: Infraestrutura, porém, para vocês terem uma ideia, no Japão um link de 100Mb por fibra ótica custa o equivalente a 60 reais por mês. Mas acredito que a Vivendi tem cacife suficiente para engolir os lixos as empresas em que somos obrigados a depender e pagar 100 reais por meros 2mb de banda com Traffic Shaping e finalmente nos prover um serviço de “primeiro mundo”.

As questões que ficam são:

Irá no final das contas a TV digital sobreviver? Ou veremos nossas mães e irmãs assistindo as novelas e discutindo com amigas em tempo real pela TV ou pelo Computador?

Após escrever essa pergunta me surgiram outras questões:

• Quanto tempo a TV Digital Brasileira irá sobreviver?
• Quanto tempo vai levar até a Globo, Record ou outra emissora começar a transmitir suas programações ao vivo e em tempo real pela internet?
• Quanto tempo irá levar para todas as mídias de massa se convergirem na Internet?

No final de tudo uma certeza eu tenho: Quem resistir vai ser engolido.

Até!

Solução:
Considerando que o repositório já está ok, e você já está conectado no remote:

Aqui estão os passos para criar o branch que a equipe vai trabalhar

# criar o branch
git checkout -b meu_branch
# enviar o branch para a origem
git push origin meu_branch
# vamos apagar esse branch local agora
git checkout master
git branch -D meu_branch

Agora cada um que vai trabalhar com este branch pode adicioná-lo assim:

git checkout --track -b meu_branch origin/meu_branch

Agora todo mundo da equipe pode trabalhar no “meu_branch” como se estivesse no master.

e para excluir o branch da origem faça:

git push origin :meu_branch

Até a proxima

1) Configurando login automático via chaves digitais no nosso servidor de armazenamento

Primeiro você tem que gerar as chaves no seu servidor de banco, com o usuário do banco de dados, no meu caso é o usuário “postgres”.

Você será perguntado por uma senha, deixe em branco e confirme:

$ su postgres
$ ssh-keygen -t dsa

Agora você terá sua chave, copie-a para seu servidor que irá armazenar o backup

$ scp ~/.ssh/id_dsa.pub user@server_bkp:~/

Agora acesse seu servidor via ssh e adicione a chave pública na lista de chaves autorizadas do ssh

$ ssh user@server_bkp
$ cat ~/id_dsa.pub >> ~/.ssh/authorized_keys

Volte para o seu servidor de banco no usuario do postgres e teste:

$ ssh user@server_bkp

Se você conseguiu acessar o server de backup sem digitar senha, continue no passo 2, senão, de uma revisada. qualquer dúvida comente!.

2) Instalando o rsync e script de backup

Para instalar o rsync no debian é bem simples:

$ aptitude install rsync

No nosso banco de dados os backups são feitos diariamente as 19 horas, e usamos a pasta /backup para armazena-los:

$ mkdir /backup
$ touch /backup/backup.sh
$ chmod +x /backup/backup.sh
$ chown postgres:postgres /backup -R

Agora, edite o arquivo backup.sh e coloque o conteúdo:

#!/bin/bash
 
PASTA=$(date +%m%Y)
DATA=$(date +%Y%m%d)
DIA=$(date +%d)
 
mkdir /backup/$PASTA
mkdir /backup/$PASTA/$DIA
 
LIST=$(psql -l | awk '{ print $1}' | grep -vE '^-|^\(|^List|^N[o|a]me|template[0|1]')
for d in $LIST
do
        pg_dump -i -h 127.0.0.1 -p 5432 -U postgres -F t -b -f "/backup/$DATA-$d.backup" $d
        tar -zcf /backup/$PASTA/$DIA/$DATA-$d.tar.gz /backup/$DATA-$d.backup
        rm /backup/$DATA-$d.backup
        /usr/bin/rsync -avzh --delete --progress --update /backup/ user@server_bkp:~/
done

faça um teste e rode o script com o user do postgres:

$ su postgres
$ /backup/backup.sh

Se tudo ocorrer bem, é só adicionar no crontab para executar quando você quiser:

$ su
$ pico /etc/crontab

e adicionar:

0 19    * * *   postgres    /backup/backup.sh

Reinicie o cron e o backup será feito todos os dias as 19 horas.

No trabalho sempre tivemos um constante problema para hospedar nossos sites: hardware!. Contamos hoje com dois incríveis servidores IBM Pentium4 3Ghz com 2gb de memória e HDs scsi, um para hospedar mais de 40 sites e o outro onde fica postgres com os bancos de dados desses sites.

Ultimamente nosso problema tem crescido bastante, pois, a demanda por sites aumentou e ao mesmo tempo o número de visitas veio aumentando e, como não conseguimos de forma alguma (até agora) investimento em equipamento novo estavamos chegando em uma situação crítica, nosso servidor começava a sentar morrer com 200 conexões simultaneas!

Lembrei-me de um post do boo-box onde vi um servidor web chamado nginx (lê-se engineX) e decidi pesquisar mais e fazer testes em casa onde rodando um servidor e servindo uma página php com um usleep de meio segundo consegui mais de 2000 conexões simultaneas! uau!..

Na segunda feira seguinte, sem pensar muito, fui para o nosso servidor de produção e apliquei a seguinte política de funcionamento:

• nginx recebe todas as conexões pela porta 80
• nginx faz proxy para o apache (que roda em outra porta) se a solicitação for para uma página php
• nginx resolve sozinho usando php-cgi caso a requisição seja para:
  • uma fotografia
  • um arquivo
  • uma requisição para o webservice
  • um download do diário oficial
  • um banner do Governo
  • a barra padrão do Estado
  • ou um arquivo na nossa lib

Como resultado da experiência, nossos sites continuam morrendo, porém, aguentando 700 conexões simultaneas e esse valor só é alcançado quando tem muita pesquisa no banco de dados (Dias que sai algo sobre algum concurso público ou muita demissão no Diário Oficial) logo, fica claro, que o problema não é mais do webserver e sim do nosso servidor de Banco. Bom, o nosso webserver atualmente mal chega a 5% de uso, mesmo com as 700 conexões. Só espero conseguir uma maquina nova e mais eficiente para os nossos Bancos de Dados logo!.

Update:
Fomos atendidos, estamos com um Xeon Quad Core com 4Gb de memória para o Banco de dados, e, associado com uma otimização do cache do webservice alcançamos mais de 1000 conexões simultâneas sem nenhuma degradação na performance. Detalhe que o webserver ainda é um P4 3ghz com 1gb de memória em que a utilização de processamento não passa de 5%.