WildBill's questions

Estou restaurando um backup de um mysqldump e notando que, se fiz adições (na forma de novas tabelas) ao banco de dados, elas persistem após a restauração. Posso voltar e remover essas tabelas para voltar ao estado original, mas como preciso testar as migrações, gostaria de trazer o banco de dados de volta ao seu estado durante o despejo sem entrar e remover manualmente as tabelas.

Suponho que poderia fazer um DROP Database XXXantes da restauração, mas isso prejudicará meus métodos de restauração atuais?

Eu quero usar o pgpool para replicar um banco de dados para outro. Eu quero fazer meu processamento em meu banco de dados mestre (leituras/gravações/inserções/exclusões), replicar esse banco de dados para outro banco de dados conforme ele é modificado e ter outras leituras direcionadas para o banco de dados replicado.

Ao ler a documentação do pgpool, parece que as leituras serão distribuídas em todos os bancos de dados do cluster. Existe uma maneira de não fazer isso e direcionar uma classe de leituras para um banco de dados e outra classe de leitura/gravação para o mestre?

Eu tenho um servidor com dois bancos de dados. Cada banco de dados possui um nome de esquema diferente, apesar do fato de o DB2 ser um subconjunto do DB1 (o DB2 possui um subconjunto das tabelas no DB1).

Apesar de quaisquer alterações de código ou arquivos de ambiente que precisem ser alterados como resultado, há algum perigo em renomear o esquema de um banco de dados PostgreSQL? Em caso afirmativo, o que? Ou um simples ALTER SCHEMA ficará bem?

Tentando executar o script de configuração slony de exemplo na documentação, mas obtendo o seguinte erro:

postgres$ /tmp/slonik_example.sh 
<stdin>:8: PGRES_FATAL_ERROR load '$libdir/slony1_funcs';  - ERROR:  could not access file "$libdir/slony1_funcs": No such file or directory 
<stdin>:8: Error: the extension for the Slony-I C functions cannot be loaded in database 'dbname=my_primary host=localhost user=warfish password=coalitions' 

No entanto, a variável LIBDIR está definida corretamente:

postgres$ ./pg_config 
BINDIR = /opt/local/lib/postgresql90/bin 
DOCDIR = /opt/local/share/doc/postgresql 
HTMLDIR = /opt/local/share/doc/postgresql 
INCLUDEDIR = /opt/local/include/postgresql90 
PKGINCLUDEDIR = /opt/local/include/postgresql90 
INCLUDEDIR-SERVER = /opt/local/include/postgresql90/server 
LIBDIR = /opt/local/lib/postgresql90 

E a lib está presente:

ls -l /opt/local/lib/postgresql90/slony1_funcs.so 
-rwxr-xr-x  1 root  admin  34944 Feb 17 16:20 /opt/local/lib/postgresql90/slony1_funcs.so 

O roteiro é o seguinte:

cat /tmp/slonik_example.sh 
#!/bin/sh 

CLUSTERNAME=slony_example; 
/opt/local/lib/postgresql90/bin/slonik <<_EOF_ 
define CLUSTERNAME slony_example; 
cluster name = @CLUSTERNAME; 
node 1 admin conninfo = 'dbname=my_primary host=localhost user=user1 password=pw'; 
node 2 admin conninfo = 'dbname=my_rep host=localhost user=user1 password=pw'; 
#-- 
# init the first node. Its id MUST be 1. This creates the schema # _$CLUSTERNAME containing all replication system specific database # objects. 
#-- 
init cluster ( id=1, comment='Master Node'); 
#-- 
# Slony-I organizes tables into sets. The smallest unit a node can # subscribe is a set. The following commands create one set containing # all 4 pgbench tables. The master or origin of the set is node 1. 
#-- 
create set (id=1, origin=1, comment='All pgbench tables'); 
set add table (set id=1, origin=1, id=1, fully qualified name='public.pgbench_accounts', comment='accounts table'); 
set add table (set id=1, origin=1, id=2, fully qualified name='public.pgbench_branches', comment='branches table'); 
set add table (set id=1, origin=1, id=3, fully qualified name='public.pgbench_tellers', comment='tellers table'); 
set add table (set id=1, origin=1, id=4, fully qualified name='public.pgbench_history', comment='history table'); 
#-- 
# Create the second node (the slave) tell the 2 nodes how to connect to Slony-I 2.1.1 Documentation 10 / 163 
# each other and how they should listen for events. 
#-- 
store node (id=2, comment = 'Slave node', event node=1); 
store path (server = 1, client = 2, conninfo='dbname=my_primary host=localhost user=user1 password=pw'); 
store path (server = 2, client = 1, conninfo='dbname=my_rep host=localhost user=user1 password=pw'); 
_EOF_ 

Leia no documento que provavelmente a lib não está no lugar correto ou $ libdir não está definido corretamente, mas tudo parece estar no lugar. Estou perdendo algo mais que não conheço?

Então eu fiz esta pergunta:

Configurando o Mongo com clustering

Mas eu não sabia o suficiente até ler as respostas e fazer mais pesquisas. É melhor usar Map-reduce ou sharding para sistemas de ritmo acelerado com ~ 100 consultas, todas feitas ao mesmo tempo? A fragmentação deslocará meus dados entre os clusters e parece que basicamente faz uma redução de mapa ou classificação. Se eu fosse usar map-reduce para tais consultas, deveria fazê-lo com um cluster também? Em caso afirmativo, é fácil começar com um servidor Mongo e, posteriormente, usar um cluster e distribuir as tarefas de redução de mapa para o cluster? Ou estou confuso sobre o que acho que preciso realizar?

Vou começar a usar o Mongo como banco de dados, mas não o colocarei em cluster no início. Posso usar o Mongo em uma única máquina e depois voltar, agrupá-lo e capitalizar o fragmento? Ou posso configurá-lo para um cluster com apenas uma máquina até ter mais para adicionar ao cluster?

Estou executando o Postgres 8.3.3. Eu tenho um banco de dados postgres em um sistema de arquivos Linux que está bastante cheio. Executei VACUUM e VACUUM FULL, mas nenhum espaço foi devolvido ao sistema operacional. Quando observo o tamanho da tabela no postgres, isso mostra que a tabela está usando consideravelmente menos espaço (até 80 MB de ~ 800 MB).

Há algo mais que deve ser executado?