We are looking to use Flyway to deploy database changes to a four-node peer-to-peer replicated Production environment. On each node the db schema/architecture is sharded horizontally across 11 partition dbs; any schema change would need to be done on each db. The way our replication is configured, not all schema changes can be run on each node; for example, sql statements to create new tables must be run on each node with additional statements to add them into replication, while statements such as adding new columns are run on only one node with the change propagating out to the other three nodes.
I'm trying to determine whether Flyway supports migrating out to multiple instances at the same time. Does anyone have experience doing this? Any tips/suggestions?
Or are there other tools out there better suited to this?
Thanks!
Related
I currently have 2 databases used by 2 services (let's call them database/service A and database/service B), both of them with their own schemas.
I need to migrate some of the tables from DB A into DB B, once that's all completed re-point service A to service B. I know could easily do the schema migration by using pg_dump utility and that seems to be the "easy" bit.
The problem I have is that both services use Flyway for database version control, hence when I re-point service A to DB B there's a bunch of migrations that are clashing on the same version number because of checksum mismatch.
I've seen that there's a "baseline" functionality in Flyway (https://flywaydb.org/documentation/command/baseline), but at first look that doesn't seem to be what I need.
How could I resolve this problem?
On first considering this problem, the immediate answer is that your move from DbB to DbA is done through one migration on top of the existing migrations in DbA. You don't try to modify the database outside of the Flyway process. Instead, you incorporate the Flyway process into your database change. Flyway is very agnostic to the set of changes you introduce. So, you're just adding another change to the existing set. This shouldn't result in a repair or a baseline to get to the required point.
Let's say the last migration for DbA is V6.3__XXX, we just add V6.4__MigratingDbB to our chain of changes. What's in that script is the necessary set of changes. That should do it.
Grant's answer is definitely the best, but an alternative solution if the database objects for the two services are completely independent, is to have two Flyway configurations which refer to the script collections for each service, and which have distinct history tables. The problem is if there are dependencies between the two services; the migrations from one service would then need to know the current state of play in the other, which could get you in a tangle actually executing them.
Are there any SQL Server Replication Best Practices? Are there any links I can read up on?
I’m using 2012 and 2014. I want to know, in general, what type of database objects typically people replicate
from the source instance (publication) to the target instance (subscription)? Table is definitely one of them.
If there are a lot of views associated with the source database and probably not being used in the replicated
database (target/subscription), should I include them in the replication process? What about stored
procedures? In both cases, would it be better just to replicate the data and manually deploy the views and
stored procedures? I’d like to get some ideas/suggestions? Thanks
Here are some resources that cover replication best practices and improving performance:
Best Practices for Replication Administration
Enhance General Replication Performance
You can find a list of database objects that can be published using Replication here:
Publish Data and Database Objects
If the objects are being used at the replicated database (subscriber) then yes, you should replicate the objects. If not, feel free to exclude them from the publication.
The benefit of including them in the publication, rather than manually deploying them, is that replication supports schema changes to published objects and when you make schema changes on appropriate published objects at the Publisher, those changes are propagated by default to all Subscribers. This is covered in Make Schema Changes on Publication Databases.
I am assinged for the task of Continuous deployment from development server to production server.
In my development server all the database objects will be created under the 'DBO' Schema. But in Production server based on every Tenants company list differenet SCHEMAS will be there.
for E.g in my development server if a tablename is created like
dbo.ABC
dbo.XYZ
And while i creating a tenant(Omkar---db) (Sarkur,Mathur--- schemas), the database objects will be like
Sarkur.ABC, sarkur.XYZ
Mathur.ABC, Mathur.XYZ
Now, i have to compare these two databases to check whether any changes in structure of the database objects, addition / deletion of database objects. If so that changes has tobe synchronized in the production database.
If anyone know that how to compare these two different schemas object, pls let me know..
1 option that I know is looking suitable
Flyway :
It is Easy to setup, simple to master. Flyway let's you regain control of your database migrations with pleasure and plain sql.
Solves only one problem and solves it well. Flyway migrates your database, so you don't have to worry about it anymore.
Made for continuous delivery. Let Flyway migrate your database on application startup. Releases have never been this easy.
Big Plus It's Open Source framework!
http://flywaydb.org/
We have a database in production that already has a good number of rows in the "user" table. Consider the following statement from the flyway website:
If you have an existing database that has not been filled by Flyway
this is the way to go:
Create an initial migration script that will recreate your current
state and give it a low version number.
Use flyway:init to create the metadata table and set this script as the current version.
I'd like to use flyway to manage my schema and various constants in the database, but I don't want V1__Base_version.sql to contain the account information for our current production users, especially considering it's stored in SCM. If I understand these instructions correctly though, I would need the ability to "recreate [my] current state" with V1__Base_version.sql.
So would creating an initial migration with just the schema and the constants work okay? Or do the databases on our workstations need to match those in production 100%?
You are correct. The init command is there to mark the production database with a version.
The initial migration you create (with the structure of your PROD db) is for the other environments. It will never run on PROD as its version will be below the init version. It will however align all environments so that subsequent migrations can be applied equally across all of them.
Little background: I'm working in a large company with a lot of branches. We have several applications with separated databases sometimes on different servers. But every database contains a table with a list of branches and their relationships. I want to automatically synchronize these tables when one of them changed.
My question is: what are the best practices of automatic synchronization of tables in different databases (Microsoft SQL Server 2008)?
Are there sql server features for that purpose? Or external tool is a good way? Or it's better to write a small application and run it as a service or use the scheduler?
You can use replication (a SQL server built-in feature) to synchronize different databases.
You can also use triggers or log shipping to sync your tables as records are added ,updated or deleted:
Here are some links about replication.
Here are some links about log shipping.