FAQ
Saludos lista

Se presenta la siguiente situacion, contamos con un servidor en producción
que tiene
un motor de base de datos Postgresql 8.2.17. En este se encuentran 20 bases
de datos. De estas solo 3 contienen informacion critica. Estas tienen un
peso de 200GB, 5GB y 375MB.

Queremos migrar esa información a un nuevo servidor mucho más eficiente y
robusto.
En el nuevo servidor se instalo la misma versión de motor de db, ya todo
está listo
solo necesitamos el montaje de un clúster o sistema de replicación que
permita
enviar en línea la información del servidor productivo al nuevo, luego
hacer el cambio de servidores,colocar como en producción el nuevo servidor y
que la información se replique en línea al que está ahora mismo en
producción.

La idea es una vez realizado el cambio de servidor, si por algún problema
que se presente es necesario volver a colocar el servidor anterior en
producción, que el cambio sea transparente para los usuarios y no se tenga
perdida de información.No tenemos el motor de base de datos en la última
versión, debido ha que tenemos muchas aplicaciones que trabajan sobre ella
que presentan problemas al trabajar con versiones de postgresql mayores a la
8.2, el trabajo de migrarlas es muy extenso y necesitamos poner en
producción pronto el nuevo servidor, porque tenemos muchas quejas de
rendimiento de nuestros usuarios.Entre los problemas que se nos han
presentando es que en gran parte de las aplicaciones se les hace substring a
campos con tipo de dato timestamp.

Las aplicaciones que trabajan sobre las bases de datos, fueron desarrolladas
en ambiente web, bajo lenguaje Java, y son varias entre esas esta el ERP de
la empresa. También la consultan Web Services y algunas aplicaciones de
escritorio hechas en java.

Considero que es un problema de las versiones, pero me inquietan las
aplicaciones. y cuales la mejor forma de hacer este cluster? ¿que
recomendaciones podrian darme?.

Comparacion de las fichas tecnicas de los servidores:
--------------------------------------------------------------------------------------------------
Actual Servidor:
Procesador= 2 procesadores Intel Xeon E5345 de 2.3 GHZ
Memoria RAM= 16 Gb
Disco duro=1 TR
Sistema Operativo=Linux Red Hat 4.1.2-14
--------------------------------------------------------------------------------------------------


Nuevo Servidor
Procesadores= 4 procesadores Intel Quad-Core Xeon E7440 / 2.4 GHZ
Memoria RAM= 32 GB (Capacidad puede aumentar hasta 128 GB)
Disco duro= 2 TR
Sistema Operativo= Linux Red Hat 4.4.4-13 (64 bits)
---------------------------------------------------------------------------------------------------

Search Discussions

  • Jaime Casanova at May 20, 2011 at 6:45 pm
    2011/5/20 Ricardo Mendoza <pgsqlcol@gmail.com>:
    Queremos migrar esa información a un nuevo servidor mucho más eficiente y
    robusto.
    En el nuevo servidor se instalo la misma versión de motor de db, ya todo
    está listo
    solo necesitamos el montaje de un clúster o sistema de replicación que
    permita
    enviar en línea la información  del servidor productivo al nuevo, luego
    hacer el cambio de servidores,colocar como en producción el nuevo servidor y
    que la información se replique en línea al que está ahora mismo en
    producción. usa slony
    Entre los problemas que se nos han
    presentando es que en gran parte de las aplicaciones se les hace substring a
    campos con tipo de dato timestamp.
    doh! a quien se le ocurre... para eso existen las funciones extract()
    y to_char()
    Considero que es un problema de las versiones, pero me inquietan las
    aplicaciones. y cuales la mejor forma de hacer este cluster? ¿que
    recomendaciones podrian darme?.
    para el cluster usa slony, lo unico es que tendras que cambiar la ip
    en las aplicaciones para que se conecten al nuevo servidor maestro (no
    trates de hacerte el listo y cambiar la ip a los servidores porque vas
    confundir a slony). Una solución podria usar una ip virtual a la que
    se conecten las aplicaciones, asi solo necesitas redireccionar la ip
    virtual y no todo.

    en cuanto a la migracion, el problema no son las versiones sino tus
    aplicaciones... y si, para migrar a una version superior probablemente
    te tocara chequear tus consultas y arreglarlas

    --
    Jaime Casanova         www.2ndQuadrant.com
    Professional PostgreSQL: Soporte y capacitación de PostgreSQL
  • Marcos Ortiz at May 20, 2011 at 8:04 pm

    On 05/20/2011 01:06 PM, Ricardo Mendoza wrote:
    Saludos lista

    Se presenta la siguiente situacion, contamos con un servidor en
    producción que tiene
    un motor de base de datos Postgresql 8.2.17. En este se encuentran 20
    bases de datos. De estas solo 3 contienen informacion critica. Estas
    tienen un peso de 200GB, 5GB y 375MB.

    Queremos migrar esa información a un nuevo servidor mucho más
    eficiente y robusto.
    En el nuevo servidor se instalo la misma versión de motor de db, ya
    todo está listo
    solo necesitamos el montaje de un clúster o sistema de replicación que
    permita
    enviar en línea la información del servidor productivo al nuevo,
    luego hacer el cambio de servidores,colocar como en producción el
    nuevo servidor y que la información se replique en línea al que está
    ahora mismo en producción.

    La idea es una vez realizado el cambio de servidor, si por algún
    problema que se presente es necesario volver a colocar el servidor
    anterior en producción, que el cambio sea transparente para los
    usuarios y no se tenga perdida de información.No tenemos el motor de
    base de datos en la última versión, debido ha que tenemos muchas
    aplicaciones que trabajan sobre ella que presentan problemas al
    trabajar con versiones de postgresql mayores a la 8.2, el trabajo de
    migrarlas es muy extenso y necesitamos poner en producción pronto el
    nuevo servidor, porque tenemos muchas quejas de rendimiento de
    nuestros usuarios.Entre los problemas que se nos han presentando es
    que en gran parte de las aplicaciones se les hace substring a campos
    con tipo de dato timestamp.

    Las aplicaciones que trabajan sobre las bases de datos,
    fueron desarrolladas en ambiente web, bajo lenguaje Java, y son varias
    entre esas esta el ERP de la empresa. También la consultan Web
    Services y algunas aplicaciones de escritorio hechas en java.

    Considero que es un problema de las versiones, pero me inquietan las
    aplicaciones. y cuales la mejor forma de hacer este cluster? ¿que
    recomendaciones podrian darme?.
    Comparacion de las fichas tecnicas de los servidores:
    --------------------------------------------------------------------------------------------------
    Actual Servidor:
    Procesador= 2 procesadores Intel Xeon E5345 de 2.3 GHZ
    Memoria RAM= 16 Gb
    Disco duro=1 TR
    Sistema Operativo=Linux Red Hat 4.1.2-14
    --------------------------------------------------------------------------------------------------


    Nuevo Servidor
    Procesadores= 4 procesadores Intel Quad-Core Xeon E7440 / 2.4 GHZ
    Memoria RAM= 32 GB (Capacidad puede aumentar hasta 128 GB)
    Disco duro= 2 TR
    Sistema Operativo= Linux Red Hat 4.4.4-13 (64 bits)
    ---------------------------------------------------------------------------------------------------
    ¿Pueden migrar a versiones más actuales de Red Hat o CentOS?
    Ambos ya están por la liberación 6, por lo que sería muy provechoso
    esto, se podrían
    obtener muchas optimizaciones y correcciones de seguridad.

    Mi segunda recomendación es que migren a la versión 9.0.4 para que
    aprovechen de a lleno todas
    las nuevas características de dicha versión que son bastantes.

    Lo otro es que leas detenidamente las notas de liberación de dicha
    versión donde explican los pasos a seguir
    para el upgrade.

    O lo otro que pudieras usar es una herramienta de replicación como
    Slony-I, Londiste o Bucardo para que hagas una replicación
    de tipo maestro-esclavo donde tu maestro sea el servidor donde tienes
    las bases de datos en 8.2 y el esclavo donde está la versión 9.0

    Como ya veo, la mayoría de las aplicaciones que usan están desarrolladas
    en Java, por lo que recomiendo que descarguen la última versión
    del driver de PostgreSQL para JDBC


    Hay muchas más recomendaciones pero la principal que puedo darte es que
    leas el Capítulo 12: Replication & Upgrades del libro de Simon Riggs y
    Hannu Krosing "PostgreSQL 9 Administration Cookbook" donde explican de
    manera genial las distintas formas que puede hacerse este engorroso trabajo.

    Saludos

    --
    Marcos Luís Ortíz Valmaseda
    Software Engineer (Large-Scaled Distributed Systems)
    University of Information Sciences,
    La Habana, Cuba
    Linux User # 418229
    http://about.me/marcosortiz
  • Ricardo Mendoza at May 20, 2011 at 8:35 pm
    Si estoy considerando esa opcion cambiar sistema operativo. o por lo menos
    una actualizacion, las aplicaciones daran mucho trabajo, y creo que es
    inaplazable la lectura del libro de simon riggs,porque veo que el asunto
    requiere mas trabajo.
  • Marcos Ortiz at May 20, 2011 at 8:53 pm

    On 05/20/2011 04:05 PM, Ricardo Mendoza wrote:
    Si estoy considerando esa opcion cambiar sistema operativo. o por lo
    menos una actualizacion, las aplicaciones daran mucho trabajo, y creo
    que es inaplazable la lectura del libro de simon riggs,porque veo que
    el asunto requiere mas trabajo.
    Verdaderamente recomiendo los dos de los colegas de 2ndQuadrant
    http://www.2ndquadrant.com/books
    El de Simon y Hannu
    y el de Greg Smith "PostgreSQL 9.0 High Performance", también de
    obligada lectura, al menos para mí.

    Mira, con el upgrade del sistema operativo puedes usar por ejemplo ext4
    como sistema de ficheros para la base de datos, ya que en ambos S.O
    (tanto en Red Hat como en CentOS) ya está incluído este sistema de
    ficheros muy estable y muy bueno para bases de datos.
    El trabajo que te espera no es fácil, por lo que debes planificarlo con
    calma y sin apuro, o simplemente contratar los servicios de expertos

    Saludos

    --
    Marcos Luís Ortíz Valmaseda
    Software Engineer (Large-Scaled Distributed Systems)
    University of Information Sciences,
    La Habana, Cuba
    Linux User # 418229
    http://about.me/marcosortiz
  • Álvaro Hernández Tortosa at May 21, 2011 at 12:11 pm
    Fri, May 20, 2011 at 04:55:18PM -0430, Marcos Ortiz escribió:
    El de Simon y Hannu
    y el de Greg Smith "PostgreSQL 9.0 High Performance", también de
    obligada lectura, al menos para mí.
    Fantástico libro, sí :)
    Mira, con el upgrade del sistema operativo puedes usar por ejemplo ext4
    Hmmmmm, ext4 puede ser una buena opción, pero también hay otras
    posiblemente buenas (xfs, por ejemplo). Pero es más, las opciones de
    montaje pueden ser determinantes en el rendimiento, como también lo es
    el particionado (todo en un mismo fs, S.O. y bbdd separadas,
    particionado diferente para logs, wal y datos, etc, etc, etc). Hay
    muchas combinaciones posibles, y la solución universal... no existe.
    Depende del uso, del tamaño de bbdd, de muchos factores. Hay que hacer
    pruebas.

    Como se ha comentado, la configuración de discos es también
    absolutamente determinante del rendimiendo, la tolerancia a fallos del
    sistema e incluso la durabilidad de los datos. Un único disco de 1TB ó
    2TB me parece a mí una muy mala elección. Yo optaría siempre por RAID
    con cierto nivel de redundancia (no creo que sea aceptable que se caiga
    la bbdd entera porque falle el disco), y asegurándonos de desactivar
    caché de escritura (o se podrían perder datos...) o con una controladora
    raid hw con baterías. Son muchos aspectos a analizar.

    Como también ha apuntado mi tocayo, no es un tema trivial esta
    migración (sea PostgreSQL o cualquier otra bbdd), y es absolutamente
    imprescindible contar con un entorno de preproducción donde reproducir
    todos los pasos previamente. Y de cara a esta migración, y en general
    para administrar dicho sistema de bbdd, sería muy recomendable que
    contaras con asistencia experta.

    Saludos y muy buena suerte,

    Álvaro

    --

    Álvaro Hernández Tortosa


    -----------
    NOSYS
    Networked Open SYStems
  • Marcos Ortiz at May 21, 2011 at 12:40 pm

    On 05/21/2011 07:41 AM, Álvaro Hernández Tortosa wrote:
    Fri, May 20, 2011 at 04:55:18PM -0430, Marcos Ortiz escribió:
    El de Simon y Hannu
    y el de Greg Smith "PostgreSQL 9.0 High Performance", también de
    obligada lectura, al menos para mí.
    Fantástico libro, sí :)
    Mira, con el upgrade del sistema operativo puedes usar por ejemplo ext4
    Hmmmmm, ext4 puede ser una buena opción, pero también hay otras
    posiblemente buenas (xfs, por ejemplo). Pero es más, las opciones de
    montaje pueden ser determinantes en el rendimiento, como también lo es
    el particionado (todo en un mismo fs, S.O. y bbdd separadas,
    particionado diferente para logs, wal y datos, etc, etc, etc). Hay
    muchas combinaciones posibles, y la solución universal... no existe.
    Depende del uso, del tamaño de bbdd, de muchos factores. Hay que hacer
    pruebas.
    XFS es una buena opción, lo que le estaba dando ext4, porque el soporte
    para los sistemas
    ext3 y ext4 están más maduros en Red Hat y CentOS que XFS
    Como se ha comentado, la configuración de discos es también
    absolutamente determinante del rendimiendo, la tolerancia a fallos del
    sistema e incluso la durabilidad de los datos. Un único disco de 1TB ó
    2TB me parece a mí una muy mala elección. Yo optaría siempre por RAID
    con cierto nivel de redundancia (no creo que sea aceptable que se caiga
    la bbdd entera porque falle el disco), y asegurándonos de desactivar
    caché de escritura (o se podrían perder datos...) o con una controladora
    raid hw con baterías. Son muchos aspectos a analizar.
    Anjá, yo usaría RAID 0 para el
    - SO
    - directorios importantes en el sistema
    - directorio del WAL

    y RAID 10 para el directorio de los datos.
    Como también ha apuntado mi tocayo, no es un tema trivial esta
    migración (sea PostgreSQL o cualquier otra bbdd), y es absolutamente
    imprescindible contar con un entorno de preproducción donde reproducir
    todos los pasos previamente. Y de cara a esta migración, y en general
    para administrar dicho sistema de bbdd, sería muy recomendable que
    contaras con asistencia experta.
    Sigo diciendo que una buena opción es contratar a expertos en el tema.
    Saludos y muy buena suerte,

    Álvaro

    --
    Marcos Luís Ortíz Valmaseda
    Software Engineer (Large-Scaled Distributed Systems)
    University of Information Sciences,
    La Habana, Cuba
    Linux User # 418229
    http://about.me/marcosortiz
  • Álvaro Hernández Tortosa at May 21, 2011 at 6:29 pm
    Sat, May 21, 2011 at 08:41:47AM -0430, Marcos Ortiz escribió:
    XFS es una buena opción, lo que le estaba dando ext4, porque el soporte
    para los sistemas
    ext3 y ext4 están más maduros en Red Hat y CentOS que XFS
    Sí, creo que así a sido, pero hasta donde yo sé en RHEL 6 XFS es
    un ciudadano de primera clase y en muy buena estima :)
    Anjá, yo usaría RAID 0 para el
    - SO
    - directorios importantes en el sistema
    - directorio del WAL
    Una pregunta, ¿RAID 0? ¿No querías decir, tal vez, RAID 1? Porque
    para el SO, pase, pero para directorios importantes del sistema o el
    WAL... en mi opinión es un riesgo muy importante, porque un RAID 0 puede
    perder datos de forma signifiativa... (la totalidad o una fracción, en
    función del modo de RAID 0 que se haga).

    Saludos,

    Álvaro

    --

    Álvaro Hernández Tortosa


    -----------
    NOSYS
    Networked Open SYStems
  • Lazaro Rubén García Martinez at May 21, 2011 at 12:57 am
    Marcos, existe algun sitio donde pueda descargar esos libros.

    Saludos.
    ________________________________________
    De: pgsql-es-ayuda-owner@postgresql.org [pgsql-es-ayuda-owner@postgresql.org] En nombre de Marcos Ortiz [mlortiz@uci.cu]
    Enviado el: viernes, 20 de mayo de 2011 16:05
    Para: Ricardo Mendoza
    CC: Lista Postgres ES
    Asunto: Re: [pgsql-es-ayuda] realizar migracion y cluster 8.2 ha ultima version
    On 05/20/2011 01:06 PM, Ricardo Mendoza wrote:
    Saludos lista

    Se presenta la siguiente situacion, contamos con un servidor en
    producción que tiene
    un motor de base de datos Postgresql 8.2.17. En este se encuentran 20
    bases de datos. De estas solo 3 contienen informacion critica. Estas
    tienen un peso de 200GB, 5GB y 375MB.

    Queremos migrar esa información a un nuevo servidor mucho más
    eficiente y robusto.
    En el nuevo servidor se instalo la misma versión de motor de db, ya
    todo está listo
    solo necesitamos el montaje de un clúster o sistema de replicación que
    permita
    enviar en línea la información del servidor productivo al nuevo,
    luego hacer el cambio de servidores,colocar como en producción el
    nuevo servidor y que la información se replique en línea al que está
    ahora mismo en producción.

    La idea es una vez realizado el cambio de servidor, si por algún
    problema que se presente es necesario volver a colocar el servidor
    anterior en producción, que el cambio sea transparente para los
    usuarios y no se tenga perdida de información.No tenemos el motor de
    base de datos en la última versión, debido ha que tenemos muchas
    aplicaciones que trabajan sobre ella que presentan problemas al
    trabajar con versiones de postgresql mayores a la 8.2, el trabajo de
    migrarlas es muy extenso y necesitamos poner en producción pronto el
    nuevo servidor, porque tenemos muchas quejas de rendimiento de
    nuestros usuarios.Entre los problemas que se nos han presentando es
    que en gran parte de las aplicaciones se les hace substring a campos
    con tipo de dato timestamp.

    Las aplicaciones que trabajan sobre las bases de datos,
    fueron desarrolladas en ambiente web, bajo lenguaje Java, y son varias
    entre esas esta el ERP de la empresa. También la consultan Web
    Services y algunas aplicaciones de escritorio hechas en java.

    Considero que es un problema de las versiones, pero me inquietan las
    aplicaciones. y cuales la mejor forma de hacer este cluster? ¿que
    recomendaciones podrian darme?.
    Comparacion de las fichas tecnicas de los servidores:
    --------------------------------------------------------------------------------------------------
    Actual Servidor:
    Procesador= 2 procesadores Intel Xeon E5345 de 2.3 GHZ
    Memoria RAM= 16 Gb
    Disco duro=1 TR
    Sistema Operativo=Linux Red Hat 4.1.2-14
    --------------------------------------------------------------------------------------------------


    Nuevo Servidor
    Procesadores= 4 procesadores Intel Quad-Core Xeon E7440 / 2.4 GHZ
    Memoria RAM= 32 GB (Capacidad puede aumentar hasta 128 GB)
    Disco duro= 2 TR
    Sistema Operativo= Linux Red Hat 4.4.4-13 (64 bits)
    ---------------------------------------------------------------------------------------------------
    ¿Pueden migrar a versiones más actuales de Red Hat o CentOS?
    Ambos ya están por la liberación 6, por lo que sería muy provechoso
    esto, se podrían
    obtener muchas optimizaciones y correcciones de seguridad.

    Mi segunda recomendación es que migren a la versión 9.0.4 para que
    aprovechen de a lleno todas
    las nuevas características de dicha versión que son bastantes.

    Lo otro es que leas detenidamente las notas de liberación de dicha
    versión donde explican los pasos a seguir
    para el upgrade.

    O lo otro que pudieras usar es una herramienta de replicación como
    Slony-I, Londiste o Bucardo para que hagas una replicación
    de tipo maestro-esclavo donde tu maestro sea el servidor donde tienes
    las bases de datos en 8.2 y el esclavo donde está la versión 9.0

    Como ya veo, la mayoría de las aplicaciones que usan están desarrolladas
    en Java, por lo que recomiendo que descarguen la última versión
    del driver de PostgreSQL para JDBC


    Hay muchas más recomendaciones pero la principal que puedo darte es que
    leas el Capítulo 12: Replication & Upgrades del libro de Simon Riggs y
    Hannu Krosing "PostgreSQL 9 Administration Cookbook" donde explican de
    manera genial las distintas formas que puede hacerse este engorroso trabajo.

    Saludos

    --
    Marcos Luís Ortíz Valmaseda
    Software Engineer (Large-Scaled Distributed Systems)
    University of Information Sciences,
    La Habana, Cuba
    Linux User # 418229
    http://about.me/marcosortiz

    -
    Enviado a la lista de correo pgsql-es-ayuda (pgsql-es-ayuda@postgresql.org)
    Para cambiar tu suscripci�n:
    http://www.postgresql.org/mailpref/pgsql-es-ayuda
  • Jaime Casanova at May 21, 2011 at 2:06 am

    2011/5/20 Lazaro Rubén García Martinez <lgarciam@vnz.uci.cu>:
    Marcos, existe algun sitio donde pueda descargar esos libros.
    A traves de este enlace los puedes comprar:
    http://2ndquadrant.co.uk/books

    --
    Jaime Casanova         www.2ndQuadrant.com
    Professional PostgreSQL: Soporte y capacitación de PostgreSQL
  • Alvaro Herrera at May 21, 2011 at 3:23 am

    Excerpts from Ricardo Mendoza's message of vie may 20 13:36:04 -0400 2011:
    Saludos lista

    Se presenta la siguiente situacion, contamos con un servidor en producción
    que tiene
    un motor de base de datos Postgresql 8.2.17. En este se encuentran 20 bases
    de datos. De estas solo 3 contienen informacion critica. Estas tienen un
    peso de 200GB, 5GB y 375MB.
    Migrar estas BDs no es trivial, y si no lo haces bien y dado que no
    tienes experiencia, te va a dar muchos dolores de cabeza. Yo te sugiero
    hacerlo con calma y tiempo; para ganar tiempo y que los usuarios dejen
    de molestar por lo lento que anda el servidor actual, sugiero corregir
    las aplicaciones para que no hagan operaciones que hacen más lento el
    sistema (como esa tontera del substring de timestamp).

    Otra cosa es que deberías tener un servidor de datos de pruebas con el
    cual verificar que tus aplicaciones funcionan tanto con 8.2 como la
    nueva versión. De esta forma te aseguras que todo funciona como debería
    con la nueva versión y no te vas a encontrar con sorpresas desagradables
    en el momento en que la migración termine.

    ¿Qué diablos es eso de disco duro 1 TR?

    Considera seriamente que puede convenirte mejorar algo el servidor
    actual (por ej. más memoria o más disco) en vez de tener que migrar todo
    a un servidor nuevo.

    Realmente, por la forma en que está planteado tu problema te
    recomendaría fuertemente que hablaras seriamente con alguien que
    sepa muy bien lo que hay que hacer.

    --
    Álvaro Herrera <alvherre@alvh.no-ip.org>
  • Jaime Casanova at May 21, 2011 at 3:30 am
    2011/5/20 Alvaro Herrera <alvherre@alvh.no-ip.org>:
    ¿Qué diablos es eso de disco duro 1 TR?

    Considera seriamente que puede convenirte mejorar algo el servidor
    actual (por ej. más memoria o más disco) en vez de tener que migrar todo
    a un servidor nuevo.
    Imagino que lo de 1TR es un Tera (aunque la abreviación no es
    correcta), y si es asi considera que un disco mas grande no es lo
    mejor... mejor varios pequeños, asi distribuyes la carga de I/O

    --
    Jaime Casanova         www.2ndQuadrant.com
    Professional PostgreSQL: Soporte y capacitación de PostgreSQL
  • Ricardo Mendoza at May 21, 2011 at 12:03 pm
    Tienes razon la abreviacion no es la correcta para terabyte. la transcribi
    mal.
  • Alvaro Herrera at May 21, 2011 at 12:12 pm

    Excerpts from Ricardo Mendoza's message of sáb may 21 08:03:12 -0400 2011:
    Tienes razon la abreviacion no es la correcta para terabyte. la transcribi
    mal.
    OK. Entonces el problema puede ser el siguiente: tu sistema de discos
    es totalmente inapropiado. ¿para qué te desgastas haciendo un upgrade
    de CPU, etc, si no mejoras en nada el sistema de almacenamiento? No es
    cuestión de subir de 1 TB a 2, sino conseguir 4 discos más y hacer un
    RAID 10.

    --
    Álvaro Herrera <alvherre@alvh.no-ip.org>
  • Ricardo Mendoza at May 21, 2011 at 12:13 pm

    Migrar estas BDs no es trivial, y si no lo haces bien y dado que no
    tienes experiencia, te va a dar muchos dolores de cabeza. Yo te sugiero
    hacerlo con calma y tiempo; para ganar tiempo y que los usuarios dejen
    de molestar por lo lento que anda el servidor actual, sugiero corregir
    las aplicaciones para que no hagan operaciones que hacen más lento el
    sistema (como esa tontera del substring de timestamp).

    Otra cosa es que deberías tener un servidor de datos de pruebas con el
    cual verificar que tus aplicaciones funcionan tanto con 8.2 como la
    nueva versión. De esta forma te aseguras que todo funciona como debería
    con la nueva versión y no te vas a encontrar con sorpresas desagradables
    en el momento en que la migración termine.

    ¿Qué diablos es eso de disco duro 1 TR?

    Considera seriamente que puede convenirte mejorar algo el servidor
    actual (por ej. más memoria o más disco) en vez de tener que migrar todo
    a un servidor nuevo.

    Realmente, por la forma en que está planteado tu problema te
    recomendaría fuertemente que hablaras seriamente con alguien que
    sepa muy bien lo que hay que hacer.

    Tienes razon, lo que hago es consultar una tercera opinion en este caso,
    de la lista de postgresql, trabajo con ingenieros y ellos son los que
    realizan todas estas tareas, yo me entero a rasgos generales del proceso y
    se toma una decision del proceso a seguir con base en criterios tecnicos, mi
    intervencion es mas en el plano administrativo, pero espero algun dia tener
    un manejo mediano de la herramienta.


    --
    Álvaro Herrera <alvherre@alvh.no-ip.org>

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
grouppgsql-es-ayuda @
categoriespostgresql
postedMay 20, '11 at 5:36p
activeMay 21, '11 at 6:29p
posts15
users6
websitepostgresql.org.es
irc#postgresql

People

Translate

site design / logo © 2022 Grokbase