Re^5: Tracking and deploying changes in (MySql/Maria) DB schema ...

This is not crazy. It works. We did it like this with a huge MySQL DB for about 10 years. Best regards, Karl

«The Crux of the Biscuit is the Apostrophe»

perl -MCrypt::CBC -E 'say Crypt::CBC->new(-key=>'kgb',-cipher=>"Blowfish")->decrypt_hex($ENV{KARL});'Help

Comment on Re^5: Tracking and deploying changes in (MySql/Maria) DB schema ... Download Code

Replies are listed 'Best First'.
Re^6: Tracking and deploying changes in (MySql/Maria) DB schema ... by soonix (Canon) on May 23, 2019 at 13:32 UTC
What about impact on resource usage? (That was my main reason for preliminarily calling it crazy)	[reply]
Re^7: Tracking and deploying changes in (MySql/Maria) DB schema ... by karlgoethebier (Abbot) on May 23, 2019 at 14:17 UTC
Terrific, to be honest. A restore of a full dump lasted one day or so. If this is what you where talking about. Totally out of question. But this case happened 2 or 3 times. In most cases it was enough to roll back/change 2 or 3 tables. Due to some strange design this had no impact on data consistency. At least the customer believed this. BTW, unfortunately MySQL dumps are plain text files. This design is totally fubar IMHO. Regards, Karl «The Crux of the Biscuit is the Apostrophe» `perl -MCrypt::CBC -E 'say Crypt::CBC->new(-key=>'kgb',-cipher=>"Blowfish")->decrypt_hex($ENV{KARL});'`Help	[reply] [d/l]
Re^8: Tracking and deploying changes in (MySql/Maria) DB schema ... by soonix (Canon) on May 24, 2019 at 05:42 UTC
No, I meant a `mysqldump --no-data …`	[reply] [d/l]
Re^9: Tracking and deploying changes in (MySql/Maria) DB schema ... by karlgoethebier (Abbot) on May 24, 2019 at 11:39 UTC