Re: How do manage running queries across multiple DB servers?

Ivan Sergio Borgonovo <[email protected]> Sat, 3 Nov 2018 10:32:17 +0100
Newsgroups gmane.org.user-groups.linux.svlug
Organization http://www.WebThatWorks.it
Message-ID <[email protected]>

On 11/2/18 5:40 PM, Robert Freiberger wrote:
> Hello,
> 
> Currently, at my workplace, we have multiple MySQL instances running 
> where they have databases for certain functions. During a deploy, we 
> need to manually SSH into the server and run these queries (stored as 
> SQL files, about 10~25 lines long queries that make table/field changes) 
> manually using the source command.
> 
> The entire process is very error-prone and time-consuming, to say the 
> least. While we have some tools written in house, I was exploring other 
> options of maybe using Puppet to store the queries in a new "deploy 
> module" and have these deployed but I like to hear from the team on 
> suggested methods.
> 
> I'm new to the world of database administration and any comments are 
> greatly welcomed.

I'm guessing the DB don't contain the same data but at least they share 
the schema and what you're trying to do is updating the schema, possibly 
moving some data around and updating stored procedures.

Don Marti gave you a very good advice.

One way to achieve this is storing in a table in the DB the schema 
version and update the schema version in the same transaction that 
change the schema.

To be extra sure you'd put the logic that check the version inside the 
transaction or think about some "locking" system that eg. avoid running 
2 update script at the same time.
You'd consider some kind of locking anyway if you're changing the schema 
because the program using the data and the data should be at the same 
version if you want to keep things easy.
Otherwise if you need some kind of HA... you should give a look at 
Refactoring Databases (Ambler, Sadalage), or maybe there is something 
newer...

To be extra sure you're not going to mess up things not only you should 
compare the current schema version with the script update version but 
apply all the "steps" to reach that version.

There are further "tricks" to expand on this idea, but this should give 
you a clue.

e.g. if your DB is made of "components", eg. on some instances you've 
some tables and in some other you don't you could version every 
component so that it would be easier to run everything you need in the 
same transaction. Or you could write "fast path" script to move you from 
version 3 to version 5 when following all the steps would be too slow etc...

-- 
Ivan Sergio Borgonovo
https://www.webthatworks.it https://www.borgonovo.net