OH3 jdbc mariadb persistence ignoring my .persist file

I have stumbled across this when I encountered some performance issue on my particular setup (synology NAS + docker image + rrd4j persistence).
I have since then uninstalled the rrd4j persistence service. I do however still use the jdbc mariadb persistence service.
My jdbc.cfg is fine, I have no issue connecting to my mariadb instance and persisting items, that all works well.
I have the following jdbc.persist, which gets loaded by openHAB (openhab.log says so):

Strategies {
    everyMinute    : "0 * * * * ?"
       every15Minutes   : "0 */15 * ? * *"    
       everyHour   : "0 0 * * * ?"
       everyDay    : "22 0 * * * *"
       default = everyChange
}
 
Items {
    
        Person1LocationHistory, Person1LocationTimeHistory, Person2LocationHistory, Person2LocationTimeHistory, Person3LocationHistory, Person3LocationTimeHistory, Person4LocationHistory, Person4LocationTimeHistory  : strategy = everyHour, restoreOnStartup
        Corona_Incidences* : strategy=everyHour, restoreOnStartup
        LastCall, SecondLastCall, ThirdLastCall, FourthLastCall : strategy = everyChange, restoreOnStartup
    }

Using the REST API as well as my mariadb browser I noticed that since I upgraded to OH3 not only these items are being persisted, but seemingly all of my items are being persisted.
I was wondering how this works. I can imagine that at some point during my investigations I have had no jdbc.persist file. And I understand that this might have caused openHAB to fall back to the new default where every item gets persisted. Even if that was the case which could explain the many hundred item tables I see in the mariadb database, I would have expected that they don’t get updated anymore when using the jdbc.persist file from above.
If I use the REST API explorer it tells me that for all of these items persistence is actually active (http://192.168.178.34:8080/rest/persistence/items) or what does it mean if they all get listed in the response?

It seems to me that openhab is persisting my items even though I don’t want it to. For whatever reason that led to performance issues with rrd4j and luckily mariadb seems to be able to handle it, but I don’t want this type of workload on the machine.

Any tips on how to debug this or ideas how to solve it are much appreciated :slight_smile:

Where did you put it?

May we see too?

I put it under conf/persistence/jdbc.persist

openHAB detects changes to it:

2021-09-29 18:32:13.520 [INFO ] [el.core.internal.ModelRepositoryImpl] - Loading model 'jdbc.persist'

Looks good. Have you actually rebooted since setting up persist file? It only gets actioned at service startup.

Yes I rebooted today and added the last line adding 4 items. And openHAB recognized that and added 4 new tables, so that seems to be working as expected, which makes me think that it probably doesn’t drop the other items as long as it finds the tables in the database. I guess I could try to drop them, after I figured out which ones (I have the default setting where they are named like Itemxxx).

I guess this was some sort of misunderstanding on my side. What happened was that in fact at some point in time all these itemxxx tables had been created (I possibly removed the jdbc.persist for some testing) and after that openHAB will not drop these table but as it seemed to me even touch some of them after a restart, at the very least it keeps them in its list of persisted items (which makes sense).
Anyway having removed all the unwanted tables as well as their entries in the items table did the trick. I am now back to a “clean” system.

1 Like

I have a trouble setting up my custom influxdb.persist file… Does it get reloaded only when I call systemctl restart openhab.service ?

I see this line in log, but is this a confirmation that my syntax is correct?

2022-10-13 22:21:21.948 [INFO ] [el.core.internal.ModelRepositoryImpl] - Loading model 'influxdb.persist'

Thanks…

No.
It might complain about syntax errors after attempting to load the file; or just ignore stuff it doesn’t like. Depends on the problem I think.