[MySQL] - Rotina para limpar bases de dados

Aqui está um script legal que vai apagar todos os seus bancos de dados MySQL, menos os bancos de dados mysql e information_schema.
Eu uso esse script sempre quando eu quero reconstruir meu servidor de replicação.

mysql -uroot -p  -e "show databases" | grep -v Database |
grep -v mysql| grep -v information_schema| grep -v test | 
grep -v OLD |gawk '{print "drop database " $1 ";select sleep(0.1);"}' |
mysql -uroot -ppassword

O comando vai criar a declaração de banco de dados apagar os bancos de dados, menos os bancos de dados mysql e information_schema.

A saída seria algo de tipo:

[root@home]#  mysql -uroot -p  -e "show databases" | grep -v Database | grep -v mysql| grep -v information_schema|grep -v bih002_bin_logs | grep -v test | grep -v OLD |gawk '{print "drop database " $1 ";select sleep(0.1);"}'
drop database callroom;select sleep(0.1);
drop database callroom_mgm;select sleep(0.1);
drop database dialogus;select sleep(0.1);
drop database limesurvey;select sleep(0.1);

Fonte: http://www.aodba.com/pt/blog/2015/02/19/como-apagar-todos-os-bancos-de-dados-em-mysql/

[MySQL] - Verificando tabelas InnoDB fragmentadas e reorganizando os dados

O que são tabelas fragmentadas?

Se houver inserções aleatórias em ou exclusões dos índices de uma tabela, os índices podem se tornar fragmentados.
A fragmentação significa que a ordem física das páginas de índice no disco não está próxima a ordem do índice dos registros nas páginas ou que há muitas páginas sem uso no bloco de 64 páginas que foram alocados para o índice.
Os sintomas de tabelas fragmentadas pode ser que a tabela pode ter mais espaço em disco do que o necessário ou os resultados pode retornar mais lento, com mais de disco I/O do que o necessário. Usuários INNODB precisa verificar a fragmentação muitas vezes, porque quando as marcas INNODB dados como excluído, ele nunca substitui os blocos com novos dados. Ele só os marca como inutilizável. Como resultado, o tamanho dos dados é artificialmente e recuperação de dados é retardado.

SELECT 
TABLE_SCHEMA, TABLE_NAME, CONCAT(ROUND(data_length / ( 1024 * 1024 ), 2), 'MB') DATA, 
CONCAT(ROUND(data_free  / ( 1024 * 1024 ), 2), 'MB')FREE 
              from information_schema.TABLES 
          where TABLE_SCHEMA 
       NOT IN ('information_schema','mysql') and Data_free < 0;

Agora crie uma rotina de executar o script abaixo.

 #!/bin/bash
 
MYSQL_LOGIN='-u<user name> --password=<passowrd>'
 
for db in $(echo "SHOW DATABASES;" | mysql $MYSQL_LOGIN | grep -v -e "Database" -e "information_schema")
do
        TABLES=$(echo "USE $db; SHOW TABLES;" | mysql $MYSQL_LOGIN |  grep -v Tables_in_)
        echo "Switching to database $db"
        for table in $TABLES
        do
                echo -n " * Optimizing table $table ... "
                echo "USE $db; OPTIMIZE TABLE $table" | mysql $MYSQL_LOGIN >/dev/null
                echo "done."
        done
done
 

É importante lembrar que quando de-fragmentam uma tabela, o processo irá bloquear a tabela, por isso certifique-se de que você pode fazer esse bloqueio.

Fonte: http://www.aodba.com/pt/blog/2015/02/19/verifique-se-ha-fragmentacao-em-mysql-e-corrigi-lo/

[PostgreSQL] - Alterando o encoding de um banco

Bem, essa dica não serve para converter um banco já existente de UTF-8 para LATIN1, para isso existem outras técnicas. A idéia apresentada aqui é para quando você tem um Dump LATIN1 e precisa restaurar em um novo servidor com o mesmo encoding, mas  o Locale de seu Sistema Operacional não permite que você crie um banco LATIN1.

O erro de Locale aparece quando você executa:

# CREATE DATABASE xpto ENCODING ‘latin1′ TEMPLATE template0;
ERROR: encoding “LATIN1″ does not match locale “pt_BR.UTF-8″
DETAIL: The chosen LC_CTYPE setting requires encoding “UTF8″.

Ocorre devido ao Locale estar configurado para UTF-8, você pode corrigir o locale, mas também pode simplesmente criar o banco em UTF-8 e depois alterar para LATIN1

# CREATE DATABASE xpto TEMPLATE template0;

Assim você acabou de criar o banco xpto com encoding UTF-8, para conferir basta dar um \l no PSQL.

Agora para alterar para LATIN1 basta executar:
# update pg_database set encoding = pg_char_to_encoding(‘LATIN1′) where datname = ‘xpto’;

Pronto, confira novamente com \l que o encoding já esta alterado.

Agora é só restaurar seu dump.

Referencia:
http://jf.eti.br/alterando-o-encoding-de-um-banco-postgresql/

[PostgreSQL] - Script para Pré-Configuração do Linux

Bom pessoal,

Abaixo, Script de pré-configuração de SO Linux :

#!/bin/bash
# insere paramentros no /etc/sysctl.conf para o postgres
echo ' ' >> /etc/sysctl.conf
echo '# postgres' >> /etc/sysctl.conf
echo 'kernel.shmmni = 4096' >> /etc/sysctl.conf
echo 'kernel.sem = 250 32000 100 128' >> /etc/sysctl.conf
echo 'net.ipv4.ip_local_port_range = 9000 65500' >> /etc/sysctl.conf
echo 'net.core.rmem_default = 1048576' >> /etc/sysctl.conf
echo 'net.core.rmem_max = 1048576' >> /etc/sysctl.conf
echo 'net.core.wmem_default = 262144' >> /etc/sysctl.conf
echo 'net.core.wmem_max = 262144' >> /etc/sysctl.conf

# recarrega confs do /etc/sysctl.conf
sysctl -p

# insere limits de utilizacao do postgres no SO
echo ' ' >> /etc/security/limits.conf
echo '# postgres' >> /etc/security/limits.conf
echo 'postgres  soft    nofile  1024' >> /etc/security/limits.conf
echo 'postgres  hard    nofile  65536' >> /etc/security/limits.conf

[PostgreSQL] - Checklist de Performance

Cinco Princípios de Hardware para Configurar o seu Servidor PostgreSQL

Discos > RAM > CPU

Se você vai gastar dinheiro em um servidor PostgreSQL, gaste em arranjos de discos de alta performance e tenha processadores medianos e uma memória adequada. Se você tiver um pouco mais de dinheiro, adquira mais RAM. PostgreSQL, como outros SGDBs que suportam ACID, utilizam E/S muito intensamente e é raro uma aplicação utilizar mais a CPU do que a placa SCSI (com algumas exceções, claro). Isto se aplica tanto a pequenos como grandes servidores; obtenha uma CPU com custo baixo se isso permitir você comprar uma placa RAID de alta performance ou vários discos.

Mais unidades de discos == Melhor

Tendo múltiplos discos, o PostgreSQL e a maioria dos sistemas operacionais irão paralelizar as requisições de leitura e gravação no banco de dados. Isto faz uma enorme diferença em sistemas transacionais, e uma significativa melhoria em aplicações onde o banco de dados inteiro não cabe na RAM. Com os tamanhos mínimos de discos (72GB) você será tentado a utilizar apenas um disco ou um único par espelhado em RAID 1; contudo, você verá que utilizando 4, 6 ou até 14 discos irá render um impulso na performance. Ah, e SCSI é ainda significativamente melhor em fluxo de dados em BD que um IDE ou mesmo um Serial ATA.

Separe o Log de Transações do Banco de Dados:

Assumindo que você já investiu dinheiro num arranjo com tamanho decente num conjunto de discos, existe um monde de opções mais inteligentes do que jogar tudo num único RAID. De inicio coloque o log de transações (pg_xlog) no seu próprio recurso de discos (um arranjo ou um disco), o que causa uma diferença de cerca de 12% na performance de bancos de dados com grande volume de gravações. Isto é especialmente vital em pequenos sistemas com discos SCSI ou IDE lentos: mesmo em um servidor com dois discos, você pode colocar o log de transações sobre o disco do sistema operacional e tirar algum benefício.

RAID 1+0/0+1 > RAID 5:

RAID 5 com 3 discos tem sido um desafortunado padrão entre vendedores de servidores econômicos. Isto possibilita a mais lenta configuração de discos possível para o PostgreSQL; você pode esperar pelo menos 50% a menos de velocidade nas consultas em relação ao obtido com discos SCSI normais. Por outro lado, foque em RAID 1 ou 1+0 para um conjunto de 2, 4 ou 6 discos. Acima de 6 discos, o RAID 5 começa a ter uma performance aceitável novamente, e a comparação tende a ser bem melhor com base na sua controladora individual. No entanto, o mais importante, usar uma placa RAID barata pode ser um risco; é sempre melhor usar RAID por software do que um incorporado numa placa Adaptec que vem com seu servidor.

Aplicações devem rodar bem junto:

Outro grande erro que eu vejo em muitas organizações e colocar o PostgreSQL em um servidor com várias outras aplicações competindo pelos mesmos recursos. O pior caso é colocar o PostgreSQL junto com outros SGDBs na mesma máquina; ambos bancos de dados irão lutar pela banda de acesso aos discos e o cache de disco do SO, e ambos vão ter uma performance pobre. Servidores de arquivo e programas de log de segurança também são ruins. O PostgreSQL pode compartilhar a mesma máquina com aplicações que utilizam principalmente CPU e RAM intensamente, como o Apache, garantindo que exista RAM suficiente.