| 1 |
> La pregunta es, puedo hacer la actualización en caliente, es decir con |
| 2 |
> postgres ejecutándose o que procedimiento es el recomendado en este tipo de |
| 3 |
> situaciones. |
| 4 |
|
| 5 |
En tu caso actual (pasar de -r2 a -r3 de una misma 'branch'), puedes |
| 6 |
emerger sin miedo la actualización. Los riesgos son cero. |
| 7 |
|
| 8 |
Otra cosa sería pasar de 7.1/2/3 a 7.4 o de esta a 8.x, porque en ambos |
| 9 |
casos cambiaron el formato de, al menos, los blobs. Para posibles casos |
| 10 |
similares de cara al futuro yo te digo que lo que hago es hacer un dump |
| 11 |
de todas las bases de datos (pero no con pg_dumpall sino con un script |
| 12 |
que hice que hace un backup de cada base de datos por separado y, una |
| 13 |
vez hechos los dumps, paro el postgres, muevo de sitio |
| 14 |
/var/lib/postgresql y emerjo la versión nueva. Después te toca hacer el |
| 15 |
initdb y volcar las bases de datos. |
| 16 |
|
| 17 |
Si surge algún problema siempre puedes volver a meter la antigua y |
| 18 |
restaurar otra vez el directorio entero. |
| 19 |
|
| 20 |
Un saludo. |
| 21 |
-- |
| 22 |
Por una UE sin PATENTES - http://EuropeSwPatentFree.hispalinux.es |
| 23 |
GnuPG key ID 0x6D2FF8B5 @ pgp.escomposlinux.org |
| 24 |
Linux/BSD BOFH - http://anurix.com/ |
| 25 |
http://fluzo.org/ |
| 26 |
|
| 27 |
-- |
| 28 |
gentoo-user-es@g.o mailing list |
Archives