A) ¿Cuál es la mejor solución para hacer copias de seguridad de una gran base de datos PostgreSQL (la versión 8.3 se ejecuta en el último servidor de Ubuntu); por favor no decir pg_dump con esas instrucciones de inserción dolorosamente lentosRestauración de PostgreSQL y solución de copia de seguridad
B) ¿Cuál es la mejor solución para la replicación de bases de datos PostgreSQL que funciona en el mundo real
A. pg_dump no utiliza instrucciones de inserción por defecto. Utilizará el comando COPY por defecto. El cambio de línea de comando de -d o --inserte hará que pg_dump ponga declaraciones de inserción en la exportación. Si tiene cualquiera de estos interruptores en su comando pg_dump, simplemente elimínelos para que pg_dump use COPY.
B. En la próxima versión de Postgres, van a tener simple replication fuera de la caja. Creo que la versión 8.4 está planeada pronto. Entonces, valdría la pena esperar por eso, si es posible.
Usted podría utilizar Online WAL-Backup tal vez en combinación de todas las noches/diario/semanal/pg_dumps mensuales. Una vez por semana/mes, debe copiar todo el clúster.
La restauración funciona bastante bien y casi no se pierden datos cuando se copia temprano (rsync es mejor ya que es muy efectivo).
La velocidad es buena, porque solo tiene que aplicar los WAL posteriores a la última copia de seguridad/copia de clúster completa.
Creo que solo hay una respuesta a eso.
PITR, o recuperación puntual. Básicamente se trata de archivar registros de transacciones, y hasta donde yo sé, es la mejor manera de hacer copias de seguridad.
Lo he configurado un par de veces para 8.1, pero debería ser el mismo en 8.3.
En el postgresql.conf todo lo que tiene que hacer es añadir lo siguiente:
archive_command = 'test ! -f /path/to/your/backups/archive_logs/%f && cp -i %p /path/to/your/backups/archive_logs/%f </dev/null'
Este comando copia los registros de archivos en el directorio especificado, en el que con seguridad puede copia de seguridad con el software de seguridad de su elección.
Para realizar una copia de seguridad completa, primero debe decirle a PostgreSQL que está realizando una copia de seguridad. Se está haciendo a través del comando psql psql "SELECT pg_start_backup('my_backup');" Después de eso simplemente copie el directorio de datos con rsync, cpio o alguna otra herramienta. Si la base de datos es muy utilizada, los archivos cambiarán durante la copia, por lo que es importante que la herramienta pueda manejarla correctamente y no rescatar.
Después de que la copia haya finalizado, simplemente ejecute psql "SELECT pg_stop_backup();" para decirle a PostgreSQL que lo detenga nuevamente. Lo que esos comandos hacen es poner un marcador en los registros de archivo en los que comenzó la copia de seguridad, por lo que en una restauración, sabe desde dónde necesita comenzar a leer desde ahí.
Esta técnica también se puede utilizar para tener un modo de espera en caliente para la replicación, pero no será legible, solo estará listo para asumir el control en caso de emergencia. El modo de espera activo completo está planificado en la versión 8.4, por lo que hasta ese momento no creo que haya otra opción.
Una cosa que es genial si usas PITR, es que puedes especificar una marca de tiempo para cuando quieras que se anexen los registros de archivo.Por lo tanto, también puede guardar la base de datos de accidentes (como eliminar o cambiar algunos datos)
pg_dump no utiliza instrucciones de inserción por defecto. Utilizará el comando COPY por defecto. El cambio de línea de comando de -d o --inserte hará que pg_dump ponga declaraciones de inserción en la exportación. ¿Quieres decir que COPY es demasiado lento? ¿O está utilizando el modificador de comando -d o --inserts? –
no sabía que podía desactivar las instrucciones de inserción, COPIA está bien..mi mal – tropikalista