@lettucemode said:@morbiuswilters said:@lettucemode said:The dumping and truncating operations will only happen during plant fuel outages - these are periods when the plant will temporarily stop operating so that the nuclear fuel can be cycled. During this time, the system that normally writes to the database won't be used. So right now I don't lock the tables since nothing else is using it, but I'll probably add it next chance I get just in case. There are no political reasons for it, so I'll pass on the trick, but thanks :)
I didn't read the whole thread, but if you're just dumping and restoring then why don't you use a hot copy? It will be much faster and can easily give you a progress since you know the size.
I didn't know what that was, so I looked it up. Looks like it's a Perl script that works on Linux or NetWare. The database is running in a Windows environment and I'd have to wade through a fair bit of red tape to get Perl installed on the workstations. Thanks, though.
Unless you mean just generally copying the actual MySQL files during downtime...that solution causes a few issues since one of the requirements is to be able to load data sets of past outages for examination while also using the application normally. I won't be on site while the plant is operating and asking the operators to do anything with MySQL directly isn't feasible.
There are scripts that do it, but a hot copy just means copying the underlying database files and loading them on another machine; it works on any OS MySQL runs on. It's much faster than a dump/reload (only really limited by the bandwidth between the machines you are copying from/to). You don't have to take the server offline to do it, although you do need to do a flush tables with read lock for MyISAM tables; InnoDB tables don't need to be flushed because they are crash-resistant. Believe me, there'd be no way to move multi-TB databases without it. However, if you don't have access to the MySQL datadir then it's a non-starter.