This shows you the differences between two versions of the page.
Both sides previous revisionPrevious revisionNext revision | Previous revision | ||
wiki:how_to_handle_a_bigger_and_bigger_oar_database [2016/06/29 14:16] – neyron | wiki:how_to_handle_a_bigger_and_bigger_oar_database [2016/06/29 20:54] (current) – [Option 1: reset the database] capitn | ||
---|---|---|---|
Line 18: | Line 18: | ||
This solution is fairly easy, but with the drawback of breaking history (e.g. job dependency if any), and forcing to stop running jobs and emptying queues (i.e. breaking the continuity of service). | This solution is fairly easy, but with the drawback of breaking history (e.g. job dependency if any), and forcing to stop running jobs and emptying queues (i.e. breaking the continuity of service). | ||
- | It involves | + | It involves |
* initialize a new database using the oar-database tool | * initialize a new database using the oar-database tool | ||
* typically with the same credentials as the former one | * typically with the same credentials as the former one | ||
Line 27: | Line 27: | ||
* admission rules: data (rows) of the admission_rules table | * admission rules: data (rows) of the admission_rules table | ||
* make sure the cluster is empty of running jobs (you may use oarnodesetting --drain command) | * make sure the cluster is empty of running jobs (you may use oarnodesetting --drain command) | ||
- | * empty the queues (waiting jobs): ask users to wait for the new database to be in service before submitting new jobs, an dedicated admission rule may help here) | + | * empty the queues (waiting jobs): ask users to wait for the new database to be in service before submitting new jobs, a dedicated admission rule may help here) |
* stop the oar-server | * stop the oar-server | ||
* change the database in use, in oar.conf (server and frontend) | * change the database in use, in oar.conf (server and frontend) |