On 16/10/14 16:02, Christopher Samuel wrote:
No worries, we're going to test out ours in a sandbox as well, so we'll
be able to compare it to our (pretty beefy) DB servers.
It took around 2 minutes to add all the indexes in our sandbox, thats
with a total of about 6 million jobs across 5
Hi Chris,
Could you define too long, and what problems it caused please?
we have tested this migration in a VM sandbox. After 30 min we decided
to interrupt the procedure and look for a faster solution.
The foreign constraints came from another database a colleague of mine
has installed, we
On 16/10/14 00:40, Ulf Markwardt wrote:
we have tested this migration in a VM sandbox. After 30 min we decided
to interrupt the procedure and look for a faster solution.
No worries, we're going to test out ours in a sandbox as well, so we'll
be able to compare it to our (pretty beefy) DB
Hiya Ulf,
On 10/10/14 20:05, Ulf Markwardt wrote:
the update procedure 2.6-14.11 of the slurmdbd adds a couple of
indexes to the database. For 10 Mio job entries this takes too
long.
Could you define too long, and what problems it caused please?
We're looking at upgrading Slurm to from
Update: A sandbox test leads to these problems:
mysql delete from taurus_job_table where time_endunix_timestamp('2013-07-01');
ERROR 1451 (23000): Cannot delete or update a parent row: a foreign key
constraint fails (`slurm_aux_acct_db`.`job_node_cpu_allocations`, CONSTRAINT
Please see the slurmdbd.conf man page:
http://slurm.schedmd.com/slurmdbd.conf.html
There are five separate configurable purge values (for jobs, steps,
reservations, events, and suspend records). None are purged by
default. Setting appropriate purge values is strongly recommended and
may
