Skip site navigation (1) Skip section navigation (2)

Re: Transportar base de datos

From: "Edwin Quijada" <listas_quijada(at)hotmail(dot)com>
To: alvherre(at)dcc(dot)uchile(dot)cl
Cc: pgsql-es-ayuda(at)postgresql(dot)org
Subject: Re: Transportar base de datos
Date: 2004-12-23 14:18:28
Message-ID: BAY1-F29D8AB068BB5E7EFD018D7E3A50@phx.gbl (view raw or flat)
Thread:
Lists: pgsql-es-ayuda
Interesante exposicion de conocimientos, Alvaro. UNa pregunta desde ahi:
Que accion hace VACUUM FREEZE y como puedo no permitir conexiones a la base 
de datos?
DOnde esta esa variable que mencionas pg_database.datallowcon?


*-------------------------------------------------------*
*-Edwin Quijada
*-Developer DataBase
*-JQ Microsistemas
*-809-747-2787
* " Si deseas lograr cosas excepcionales debes de hacer cosas fuera de lo 
comun"
*-------------------------------------------------------*



>From: Alvaro Herrera <alvherre(at)dcc(dot)uchile(dot)cl>
>To: Ariel Romero <aromero(at)cenatav(dot)co(dot)cu>
>CC: Lista de correo postgres <pgsql-es-ayuda(at)postgresql(dot)org>
>Subject: Re: [pgsql-es-ayuda] Transportar base de datos
>Date: Wed, 22 Dec 2004 18:43:37 -0300
>
>On Wed, Dec 22, 2004 at 05:06:03PM -0500, Ariel Romero wrote:
>
>Hola,
>
> >    Quiero transportar una base de datos postgres de un servidor 
>llevándome
> > toda la base de datos en un disco para llevarla a otro servidor en otro
> > lugar.
> >   En MSSQL es muy facil: desatacho la base de datos, copio la BD, 
>transporto
> > y vuelvo a atachar la BD en otro lugar y listo.
> >   Pero con postgres NO SE.
>
>La respuesta canonica seria "haz un respaldo y lo recuperas al otro
>lado".
>
>La segunda respuesta seria "baja postmaster, toma PGDATA completo, y
>levantalo al otro lado", pero eso llevaria todas tus bases de datos (no
>solo una), y no puedes hacerlo coexistir con otras bases de datos en el
>otro lado.
>
>La tercera respuesta te permitiria llevar solo una sin tener que hacer
>el dump:
>
>1. conectate a la BD en cuestion
>2. prohibe conexiones a ella para asegurarte que nadie echara a perder
>nada (pg_database.datallowcon = false)
>3. aplicale VACUUM FREEZE (*)
>4. baja postmaster
>5. en el otro lado, crea los usuarios y grupos que sean relevantes, con
>los mismos SYSIDs de la base de datos antigua
>6. crea una nueva base de datos en el otro lado, y baja postmaster
>7. borra el directorio de la BD del otro lado, y pon el directorio de la
>BD que quieres transportar.  Cambia el nombre del directorio al OID de
>la base de datos que creaste en el paso 6 (pg_database.oid)
>
>
>En este procedimiento tendras que tener cuidado adicional si tienes
>alguna tabla en algun tablespace (obviamente, solo en 8.0).  Ademas, es
>completamente teorico, nunca lo he probado y nunca he visto que nadie lo
>recomiende ni que lo haga antes.
>
>En principio, en Postgres 7.4 podria funcionar sin problemas.  En 8.0
>podrias tener dramas con tablespaces, si los usas.  En 8.1 sera mas
>dificil hacerlo, debido a que probablemente no habra provisiones para
>crear usuarios con SYSIDs determinados.
>
>Hmm ... se me ocurre que podria haber problemas con el archivo de cache
>interno.  Para evitarlo, borra el archivo pg_internal.init del
>directorio que estas moviendo (se reconstruye automaticamente al
>partir).
>
>
>(*) el procedimiento funciona porque despues de VACUUM FREEZE, los datos
>que hay en las tablas son independientes de pg_clog.
>
>--
>Alvaro Herrera (<alvherre[(at)]dcc(dot)uchile(dot)cl>)
>"La conclusión que podemos sacar de esos estudios es que
>no podemos sacar ninguna conclusión de ellos" (Tanenbaum)
>
>---------------------------(end of broadcast)---------------------------
>TIP 9: el optimizador ignorará el uso de recorridos de índice si los
>        tipos de datos de las columnas no coinciden

_________________________________________________________________
MSN Amor: busca tu ½ naranja http://latam.msn.com/amor/


In response to

Responses

pgsql-es-ayuda by date

Next:From: Jorge TinitanaDate: 2004-12-23 14:29:32
Subject: Fwd: Feliz Navidad
Previous:From: .:J:.Date: 2004-12-23 13:44:15
Subject: Re: - Triggers que actualizen tablas en otro motor

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group