I found an acceptable workaround: I create two persistent volumes, one RWO for the database to write to, and one RWX to write the backup to. The RWX can be connected to from the cronjob container. But a remote client backup remains a good idea.
It would be great if there is a way to create a dump of the database from a client, like pg_dump for postgres. I'm using HSQLDB for smaller "MSAccess" alike projects. One jar, starts its own database (hsqldb in server mode), and off you go. Installation is a simple copy, backup is a sql command plus a simple copy. Love it. I've deployed the application in a container on Kubernetes now and that suddenly complicate things. Especially because persistent volumes in RWO mode cannot be shared between containers....
It would be great if there is a way to create a dump of the database from a client, like pg_dump for postgres. I'm using HSQLDB for smaller "MSAccess" alike projects. One jar, starts its own database (hsqldb in server mode), and off you go. Installation is a simple copy, backup is a sql command plus a simple copy. Love it. I've deployed the application in a container on Kubernetes now and that suddenly complicate things. Especially because persistent volumes in RWO mode cannot be shared between containers....
The follow-up question would be: can I put all nodes in one group and broadcast (push) any changes? All documentation and examples seem to focus on the corp/store setup. And the answer is: yes! Okay. Interesting!
Ahhh, okay, the community edition is very very barebone. I made some assumptions. Thank you. (I have the expected triggers now.)
The follow-up question would be: can I put all nodes in one group and broadcast (push) any changes? All documentation and examples seem to focus on the corp/store setup.
Ahhh, okay, the community edition is very very barebone. I made some assumptions. Thank you.
I've got a hsqldb in server mode, SymmetricDS running in stand alone mode, and sym tables and triggers have been created with the symadmin create-sym-tables and sync-triggers commands. Since hsqldb does not provide a roll forward log (and because I use the community version), there need to be triggers on each table to capture changes. If I inspect hsqdbl's information schema (SELECT * FROM INFORMATION_SCHEMA.TRIGGERS) I see only triggers on SYM tables, no triggers on my actual data tables. When running...