¿Cómo puedo poner una base de datos bajo git (control de versiones)?

Echa un vistazo a las bases de datos de refactorización ( http://databaserefactoring.com / ) para un montón de buenas técnicas para mantener su base de datos en conjunto con los cambios de código.

Basta con decir que estás haciendo las preguntas equivocadas. En lugar de poner su base de datos en git, debería descomponer sus cambios en pequeños pasos verificables para que pueda migrar/revertir los cambios del esquema con facilidad.

Si desea tener una recuperabilidad completa, debe considerar archivar su postgres WAL registra y usa el PITR (point in time recovery) para reproducir / reenviar transacciones a estados buenos conocidos específicos.

Estoy empezando a pensar en una solución muy simple, no sé por qué no pensé en ella antes!!

• Duplique la base de datos (tanto el esquema como los datos).
• En la rama de new-major-changes, simplemente cambie la configuración del proyecto para usar la nueva base de datos duplicada.

De esta manera puedo cambiar de rama sin preocuparme por los cambios en el esquema de la base de datos.

EDITAR:

Por duplicado, me refiero a crear otra base de datos con un nombre diferente (like my_db_2); no hacer un volcado ni nada por el estilo.

En lugar de descargar manualmente tu base de datos y guardarla en git, usa Offscale DataGrove.

DataGrove es básicamente un control de versiones de BD - rastrea los cambios en toda la BD (esquema y datos) y le permite etiquetar versiones en su repositorio. Puedes usarlo junto con git y hacer que etiquete una versión cada vez que registres el código, y cargar el estado de BASE de datos correcto cada vez que extraigas el código.

Específicamente con respecto a "Edit 2" - con DataGrove puede simplemente tener dos ramas de la base de datos, una para cada una de las ramas de código. Cuando cargue una rama determinada del código, DataGrove volverá a crear automáticamente todo el estado de la base de datos, con todos los datos dentro de esa versión / rama. Esto significa que puede cambiar entre ramas de desarrollo con un solo comando.

Use algo como LiquiBase esto le permite mantener el control de revisión de sus archivos Liquibase. puede etiquetar los cambios solo para producción, y hacer que lb mantenga su base de datos actualizada para producción o desarrollo (o cualquier esquema que desee).

Hay una herramienta que está en desarrollo llamada Klonio, cuya versión beta está disponible para su uso. Es compatible con MongoDB y MySQL a partir de ahora.

Por supuesto, tiene integración con git y puede capturar su esquema solo o incluso los datos incluidos.

Hay un gran proyecto llamado Migraciones bajo Doctrina que se construyó solo para este propósito.

Todavía está en estado alfa y construido para php.

Http://docs.doctrine-project.org/projects/doctrine-migrations/en/latest/index.html

Eche un vistazo al Control de código fuente SQL de RedGate.

Http://www.red-gate.com/products/sql-development/sql-source-control /

Esta herramienta es un complemento de SQL Server Management Studio que le permitirá colocar su base de datos bajo Control de código fuente con Git.

Es un poco caro en $495 por usuario, pero hay una prueba gratuita de 28 días disponible.

NOTA No estoy afiliado con RedGate de ninguna manera.

Me he encontrado con esta pregunta, ya que tengo un problema similar, donde algo que se aproxima a una estructura de directorios basada en bases de datos, almacena 'archivos', y necesito git para administrarlo. Se distribuye, a través de una nube, utilizando replicación, por lo tanto, su punto de acceso será a través de MySQL.

La esencia de las respuestas anteriores, parecen sugerir de manera similar una solución alternativa al problema preguntado, que tipo de pierde el punto, de usar Git para administrar algo en una base de datos, así que intentaré responder esa pregunta.

Git es un sistema, que en esencia almacena una base de datos de deltas (diferencias), que se pueden volver a montar, con el fin de reproducir un contexto. El uso normal de git asume que el contexto es un sistema de archivos, y esos deltas son diff en ese sistema de archivos, pero realmente todo git es, es una base de datos jerárquica de deltas (jerárquica, porque en la mayoría de los casos cada delta es un commit con al menos 1 padres, dispuestos en un árbol).

Siempre y cuando se puede generar un delta, en teoría, git puede almacenarlo. El problema es que normalmente git espera que el contexto, en el que está generando delta, sea un sistema de archivos, y de manera similar, cuando compras un punto en la jerarquía de git, espera generar un sistema de archivos.

Si desea administrar el cambio, en una base de datos, tiene 2 problemas discretos, y los abordaría por separado (si fuera usted). El primero es el esquema, el segundo son los datos (aunque en tu pregunta, dices que los datos no son algo que te preocupe). Un el problema que tuve en el pasado, era una base de datos Dev y Prod, donde Dev podía tomar cambios incrementales en el esquema, y esos cambios tenían que ser documentados en CVS, y propogados para vivir, junto con adiciones a una de varias tablas 'estáticas'. Lo hicimos al tener una 3ra base de datos, llamada Cruise, que contenía solo los datos estáticos. En cualquier momento se podía comparar el esquema de Dev y Cruise, y teníamos un script para tomar la diferencia de esos 2 archivos y producir un archivo SQL que contenía ALTER declaraciones, para aplicarlo. Del mismo modo, cualquier dato nuevo, podría ser destilado a un archivo SQL que contiene comandos INSERT. Siempre que los campos y las tablas solo se agreguen y nunca se eliminen, el proceso podría automatizar la generación de las instrucciones SQL para aplicar el delta.

El mecanismo por el cual git genera deltas es diff y el mecanismo por el cual combina 1 o más deltas con un archivo, se llama merge. Si puedes encontrar un método para diferenciar y fusionar desde un contexto diferente, git debería funcionar, pero como se ha discutido, es posible que prefiera una herramienta que lo haga por usted. Mi primer pensamiento hacia la solución que es este https://git-scm.com/book/en/v2/Customizing-Git-Git-Configuration#External-Merge-and-Diff-Tools que detalla cómo reemplazar la herramienta de comparación y combinación interna de git. Actualizaré esta respuesta, ya que se me ocurre una mejor solución al problema, pero en mi caso espero solo tener que administrar los cambios de datos, en-tan-lejos-como un archivo basado en DB puede cambiar, por lo que mi la solución puede no ser exactamente lo que necesita.

No puedes hacerlo sin atomicity, y no puedes obtener atomicity sin usar pg_dump o un sistema de archivos snapshotting.

Mi instancia de postgres está en zfs, que hago instantáneas ocasionalmente. Es aproximadamente instantáneo y consistente.

Lo que quieres, en espíritu, es quizás algo como Post Facto, que almacena versiones de una base de datos en una base de datos. Compruebe esta presentación.

El proyecto aparentemente nunca llegó a ninguna parte, por lo que probablemente no te ayudará de inmediato, pero es un concepto interesante. Me temo que hacer esto correctamente sería muy difícil, porque incluso la versión 1 tendría que obtener todos los detalles correctos para que la gente confíe en su trabajo.

He lanzado una herramienta para sqlite que hace lo que estás pidiendo. Utiliza un controlador de diferencias personalizado que aprovecha la herramienta de proyectos sqlite 'sqldiff', UUIDs como claves primarias, y deja fuera el rowid sqlite. Todavía está en alfa por lo que la retroalimentación es apreciada.

Postgres y mysql son más complicados, ya que los datos binarios se guardan en varios archivos y puede que ni siquiera sean válidos si se puede hacer una instantánea de ellos.

Https://github.com/cannadayr/git-sqlite

Quiero hacer algo similar, agregar mis cambios de base de datos a mi sistema de control de versiones.

Voy a seguir las ideas en este post de Vladimir Khorikov "Database versioning best practices". En resumen,

• almacena tanto su esquema como los datos de referencia en un sistema de control de código fuente.
• para cada modificación crearemos un script SQL separado con los cambios

En caso de que ayude!

Creo que X-Istence está en el camino correcto, pero hay algunas mejoras más que puede hacer a esta estrategia. Primero, use:

$pg_dump --schema ... 

Para volcar las tablas, secuencias, etc y colocar este archivo bajo control de versiones. Usarás esto para separar los cambios de compatibilidad entre tus ramas.

A continuación, realice un volcado de datos para el conjunto de tablas que contienen la configuración requerida para que su aplicación funcione (probablemente debería omitir datos de usuario, etc.), como los valores predeterminados del formulario y otros datos datos no modificables por el usuario. Puedes hacer esto selectivamente usando:

$pg_dump --table=.. <or> --exclude-table=..

Esta es una buena idea porque el repositorio puede ser realmente torpe cuando su base de datos llega a 100Mb+ al hacer un volcado de datos completo. Una mejor idea es hacer una copia de seguridad de un conjunto más mínimo de datos que necesita para probar su aplicación. Sin embargo, si sus datos predeterminados son muy grandes, esto puede causar problemas.

Si es absolutamente necesario colocar copias de seguridad completas en el repositorio, considere hacerlo en una rama externa de su árbol fuente. Sin embargo, un sistema de respaldo externo con alguna referencia al svn rev correspondiente es probablemente el mejor para esto.

Además, sugiero usar volcados de formato de texto sobre binario para propósitos de revisión (al menos para el esquema) ya que son más fáciles de diferenciar. Siempre puede comprimirlos para ahorrar espacio antes de registrarse.

Finalmente, eche un vistazo a la documentación de copia de seguridad de postgres si aún no lo ha hecho. La forma en que está comentando sobre la copia de seguridad de 'la base de datos' en lugar que un volcado me hace preguntarme si está pensando en copias de seguridad basadas en el sistema de archivos (consulte la sección 23.2 para salvedades).

Esta pregunta está bastante respondida, pero me gustaría complementar la respuesta de X-Istence y Dana la Cuerda con una pequeña sugerencia.

Si necesita un control de revisión con cierto grado de granularidad, por ejemplo a diario, podría acoplar el volcado de texto tanto de las tablas como del esquema con una herramienta como rdiff-backup que hace copias de seguridad incrementales. La ventaja es que en lugar de almacenar instantáneas de copias de seguridad diarias, simplemente almacena las diferencias de las anteriores dia.

Con esto tiene la ventaja del control de revisiones y no pierde demasiado espacio.

En cualquier caso, usar git directamente en archivos planos grandes que cambian con mucha frecuencia no es una buena solución. Si su base de datos se vuelve demasiado grande, git comenzará a tener algunos problemas para administrar los archivos.

Yo recomendaría neXtep para la versión que controla la base de datos tiene un buen conjunto de documentación y foros que explica cómo instalar y los errores encontrados. Lo he probado para PostgreSQL 9.1 y 9.3, pude hacerlo funcionar para 9.1 pero para 9.3 no parece funcionar.

Lo que hago en mis proyectos personales es almacenar toda mi base de datos en dropbox y luego apuntar MAMP, WAMP workflow para usarlo desde allí.. De esa manera, la base de datos siempre está actualizada donde sea que necesite desarrollar algo. ¡Pero eso es solo para Dev! Sitios en vivo está utilizando el propio servidor para que fuera de curso! :)

Almacenar cada nivel de cambios en la base de datosbajo el control de versiones de git es como empujar toda la base de datos con cada confirmación y restaurar toda la base de datos con cada extracción. Si su base de datos es tan propensa a cambios cruciales y no puede permitirse perderlos, puede actualizar sus ganchos pre_commit y post_merge. Hice lo mismo con uno de mis proyectos y puedes encontrar las direcciones aquí.

Así es como lo hago:

Dado que tiene libre elección sobre el tipo de DB, use una base de datos basada en archivos como, por ejemplo, firebird.

Cree una base de datos de plantilla que tenga el esquema que se ajuste a su rama real y guárdela en su repositorio.

Al ejecutar su aplicación mediante programación, cree una copia de su base de datos de plantillas, guárdela en otro lugar y simplemente trabaje con esa copia.

De esta manera puede poner su esquema de base de datos bajo control de versiones sin los datos. Y si cambias tu esquema solo tienes que cambiar la plantilla DB

Solíamos ejecutar un sitio web social, con una configuración estándar de LAMP. Teníamos un servidor en vivo, un servidor de prueba y un servidor de Desarrollo, así como las máquinas de desarrolladores locales. Todos fueron administrados usando GIT.

En cada máquina, teníamos los archivos PHP, pero también el servicio MySQL, y una carpeta con Imágenes que los usuarios subirían. El servidor en vivo creció hasta tener unos 100K (!) usuarios recurrentes, el volcado era de aproximadamente 2 GB (!) , la carpeta de imágenes era de unos 50 GB (!). Cuando me fui, nuestro servidor estaba alcanzando el límite de su CPU, Ram y, sobre todo, los límites de conexión de red concurrentes (Incluso compilamos nuestra propia versión del controlador de tarjeta de red para maximizar el servidor 'lol'). No pudimos (ni debes asumir con tu sitio web) poner 2GB de datos y 50GB de imágenes en GIT.

Para gestionar todo esto en GIT fácilmente, ignoraríamos las carpetas binarias (las carpetas que contienen las Imágenes) insertando estas rutas de carpeta en .gitignore. También teníamos una carpeta llamada SQL fuera de la Ruta de Apache documentroot. En esa carpeta SQL, pondríamos nuestros archivos SQL de los desarrolladores en números incrementales (001.florianm.sql, 001.John.sql, 002.florianm.sql, etc.). Estos archivos SQL también fueron administrados por GIT. El primer archivo sql de hecho contendría un gran conjunto de esquemas de BD. No agregamos datos de usuario en GIT (por ejemplo, los registros de la tabla users, o la tabla comments), pero datos como configs o topología u otros datos específicos del sitio, se mantuvieron en los archivos sql (y por lo tanto por GIT). En su mayoría son los desarrolladores (que conocen mejor el código) que determinan qué y qué no es mantenido por GIT con respecto al esquema SQL y los datos.

Cuando llega a una versión, el administrador inicia sesión en el servidor dev, fusiona la rama live con todos los desarrolladores y las ramas necesarias en la máquina dev a una rama update, y la envía al servidor de prueba. En el servidor de prueba, comprueba si el proceso de actualización para el servidor en vivo sigue siendo válido, y en rápida sucesión, señala todo el tráfico en Apache a un sitio de marcador de posición, crea un volcado de base de datos, apunta el directorio de trabajo de 'live' a 'update', ejecuta todos los nuevos archivos sql en mysql, y devuelve el tráfico al sitio correcto. Cuando todas las partes interesadas estuvieron de acuerdo después de revisar el servidor de prueba, el Administrador hizo lo mismo del servidor de prueba al servidor en vivo. Después, se fusiona la rama en vivo en el servidor de producción, a la rama principal a través de todos los servidores, y rebasado todas las ramas en vivo. Los desarrolladores fueron responsables ellos mismos para rebase sus ramas, pero generalmente saben lo que están haciendo.

Si hubo problemas en el servidor de prueba, por ejemplo. las fusiones tenían demasiados conflictos, luego el código se revirtió (apuntando la rama de trabajo de nuevo a 'live') y los archivos sql nunca se ejecutaron. En el momento en que se ejecutaron los archivos sql, esto se consideró como una acción irreversible en ese momento. Si los archivos SQL no funcionaban correctamente, entonces la base de datos se restauraba usando el volcado (y los desarrolladores regañado, por proporcionar archivos SQL mal probados).

Hoy en día, mantenemos una carpeta sql-up y sql-down, con nombres de archivo equivalentes, donde los desarrolladores tienen que probar que ambos archivos sql de actualización pueden ser igualmente degradados. En última instancia, esto podría ejecutarse con un script bash, pero es una buena idea si human eyes siguiera monitoreando el proceso de actualización.

No es genial, pero es manejable. Espero que esto dé una idea de un sitio de la vida real, práctico y relativamente de alta disponibilidad. Sea un poco anticuado, pero aún así seguido.

Utilice una herramienta como iBATIS Migrations ( manual, breve video tutorial ) que le permite controlar la versión los cambios que realiza en una base de datos a lo largo del ciclo de vida de un proyecto, en lugar de la base de datos en sí.

Esto le permite aplicar selectivamente cambios individuales a diferentes entornos, mantener un registro de cambios de qué cambios son en qué entornos, crear scripts para aplicar cambios de A a N, cambios de reversión, etc.

Me gustaría poner toda la base de datos bajo control de versiones, lo que motor de base de datos puedo utilizar para que pueda poner la base de datos real bajo ¿control de versiones en lugar de su volcado?

Esto no depende del motor de base de datos. Por Microsoft SQL Server hay un montón de programas de control de versiones. No creo que ese problema se pueda resolver con git, tienes que usar un sistema de control de versiones de esquema específico de pgsql. No se si tal cosa existe o no...

Esto es lo que estoy tratando de hacer en mis proyectos:

• separe los datos y el esquema y los datos predeterminados.

La configuración de la base de datos se almacena en un archivo de configuración que no está bajo control de versiones (.gitignore)

Los valores predeterminados de la base de datos (para configurar nuevos proyectos) es un simple archivo SQL bajo control de versiones.

Para el esquema de base de datos cree un volcado de esquema de base de datos bajo el control de versiones.

La forma más común es tener scripts de actualización que contiene sentencias SQL, (ALTER Table.. o ACTUALIZAR). También necesita tener un lugar en su base de datos donde guardar la versión actual de su esquema)

Echa un vistazo a otros grandes de código abierto base de datos de proyectos (piwik,o su favorito de sistema cms), todos ellos de uso updatescripts (1.sql,2.sql,3.sh,4.php.5.sql)

Pero este es un trabajo que requiere mucho tiempo, debe crear y probar los updatescripts y debe ejecutar un updatescript común que compare la versión y ejecute todo lo necesario actualizar scripts.

Así que teóricamente (y eso es lo que estoy buscando) usted podría volcado el esquema de la base de datos después de cada cambio (manualmente, conjob, git hooks (tal vez antes de la confirmación)) (y solo en algunos casos muy especiales crear updatescripts)

Después de eso en su updatescript común (ejecute los updatescripts normales, para los casos especiales) y luego compare los esquemas (el volcado y la base de datos actual) y luego genere automáticamente las instrucciones ALTER nessesary. Hay algunas herramientas que puede hacer esto ya,pero no he encontrado todavía una buena.

Se enfrentó a una necesidad similar y esto es lo que arrojó mi investigación sobre los sistemas de control de versiones de bases de datos:

1. Sqitch-código abierto basado en perl; disponible para todas las principales bases de datos, incluyendo PostgreSQL https://github.com/sqitchers/sqitch
2. Mahout - solo para PostgreSQL; control de versiones de esquemas de base de datos de código abierto. https://github.com/cbbrowne/mahout
3. Liquibase - otro sw de control de versiones de código abierto db. versión gratuita de Datical. http://www.liquibase.org/index.html
4. Datical - versión comercial de Liquibase - https://www.datical.com /
5. Flyway by BoxFuse-commercial sw. https://flywaydb.org /
6. Otro proyecto de código abierto https://gitlab.com/depesz/Versioning El autor proporciona una guía aquí: https://www.depesz.com/2010/08/22/versioning /
7. Red Gate Change Automation - solo para SQL Server. https://www.red-gate.com/products/sql-development/sql-change-automation /