There is no problem with duplicated JobIDs. from https://slurm.schedmd.com/sacct.html *-D**,* *--duplicates* If Slurm job ids are reset, some job numbers will probably appear more than once in the accounting log file but refer to different jobs. Such jobs can be distinguished by the "submit" time stamp in the data records.
When data for specific jobs are requested with the --jobs option, *sacct* returns the most recent job with that number. This behavior can be overridden by specifying --duplicates, in which case all records that match the selection criteria will be returned. NOTE: Revoked federated sibling jobs are hidden unless the --duplicates option is specified. El mié., 8 jul. 2020 a las 13:58, Brian Andrus (<toomuc...@gmail.com>) escribió: > If you want everything good, you will want to dump/import before > starting to use the new database. > > If they are the same versions of mysql/mariadb, I would merely rsync the > database folders over and then start the db. > > One potential gotcha is the jobid starting over/being different. Make > sure you set that in the slurm.conf to continue the numbering from where > you left off so there are no entries in accounting that get replaced. > > Brian Andrus > > On 7/8/2020 3:15 AM, Simon Kainz wrote: > > Hello, > > > > we have a long-running slurm cluster, accounting into slurmdbd/mysql > > backend on the cluster master. > > > > We recently installed a new system, now with a dedicated, separate > > logging host, also with mysql backend. > > > > How could i, preferably without losing accounting data, move the logging > > information from the old system into the new one? > > > > Just changing the logging config on the old system, adding the old > > system via sacctmgr and then dumping/importing the relevant tables into > > the new host? > > > > Are there any pitfalls to this idea? > > > > Thank you in advance, > > > > Simon. > > > >
