Our server 5.4 is bound to a remote sql server database for journal. Our sql server failed last saturday.
In this case I understand EM uses the embedded journal first, and indeed we saw the embedded journal has been used to write logs.
The problem is the web intercace : if EM switch to embedded journal, the web interface continues to show things related to the remote database which is off in our case. So we don’t get access to logs, we have an error message in red saying that the remote journal is not available.
I guess that in this case we have to manually switch the configuration to “embedded journal” in order to get access to the content trough the web interface. Then when the remote database is up again, we have to switch back the configuration manually. It’s not automated but It may be an issue because I guess it should be fully automated ?
The Journal switches to the embedded database automatically when connecting to the external database fails even after a few retries. To remedy the situation the connection external database has to be fixed. This requires intervention of a system/DB administrator and can’t be done automatically. When the problem is fixed, the journal should be manually switched to the external database, also the journal records created in the embedded database while the external database wasn’t available should be moved to the external database (it can be done with an EasyMorph workflow).
During the period where the remote db is down and the journal switches to embedded database, how the web interface is supposed to behave ? Rendering the content of the embedded database or showing nothing but an error message ?
Yes, while the external DB is not available, the journal only shows the error message and the “Try again” link. No other records are shown. Message “Switching to using the embedded journal database because the external journal database is no longer accessible” is written in the Server log.
Ok I understand it is the expected behaviour. It would have been better to enable an access to the logs during the down time but well, the highest priority remains to set the remote database back up in this case.
