Community Edition 7.0.5 VM broken?

[drahman]

Hello,

I downloaded the new version (7.0.5) of the community edition vm for virtual box. It successfully imported the appliance, but after a shutdown and new start later on, all volumes are gone. Changes I did:

• added DNS (8.8.8.8)
• added NTP-Server (pool.ntp.org)
• synchronized time
• added schema and tables for testing

Previous versions of VM work fine an keep their settings after restart.

Thanks in advance.

[exa-Chris]

Good Morning, let me check internally. Rgds Christian

[exa-Nico]

Sometimes I have had issues when shutting down the VM that the volumes disappear. This has only happened once or twice with me over several years, and I can never reproduce it.  How did you shutdown the VM? Power off or sending the shutdown signal? 

I haven't been able to recover it after that point. To avoid it though, it's best to make shut down the database and storage before shutting down the VM. Even better would be to just save the machine state instead of shutting it down. My guess is that the sudden "power off" somehow corrupts the storage/volumes, which causes the database not to start afterwards. 

[drahman]

Hi,

thanks for your reply. I power off through the provided menu over Virtual Box:

And with previous Versions I have (v6.2.11 and v7.0.3) the shutdown process does work, this only happens with v7.0.5, every time, which is strange. I'm testing the FBV-Export to S3-Bucket which should be fixed with this new version. But it appears that the bug still appears with

ETL-5106: Following error occured while writing data to external connection [<S3-Bucket-Path> failed with error code=400 after 0 bytes.] (Session: 1687802083330555904)

CSV-Export to S3-Bucket works fine, also FBV-Export to local works fine, only FBV-Export to S3 doesn't work. That's why im using the new version. And loosing the volumes is somewhat inconvenient.

So with the available Community Edition 7.0.5 in Virtual Box you can normally shutdown and restart the VM, without loosing the volumes?

[exa-Nico]

Ok, so you mean that it is reproducible every time on 7.0.5 Community Edition? 

I will also give it a few tries... 

[drahman]

Hi,

yes - at least with me. I will will double-check with a colleague of mine if he can download the new version and try it out.  If it works normally with you, or with my colleague then maybe something else is broken. I might try redownloading it later this day. It is weird...

[exa-Nico]

@drahman I have managed to reproduce the issue on 7.0.5. I also haven't seen this before, so I opened up an internal ticket for development to investigate it. Those exact steps you said worked on 7.0.3, right? 

[drahman]

@exa-Nico I double checked right now, on 7.0.3 i didn't add the ntp-time-server and didn't synchronize it (there I didn't get a time-skew error from AWS). After adding and synchronizing I could reproduce the error on 7.0.3 also. So it looks like that adding a ntp-server and synchronizing the time somehow messes up either the shutdown, or startup sequence and it looses all volumes.

[exa-Nico]

Ok, so it's a bigger problem then. I think you are right, somehow the addition of the ntp server and time syncronization breaks the shutdown or startup sequence. Let's see what development says. I'll keep you posted

[exa-Nico · Accepted solution]

@drahman so, development has confirmed it is a bug. There are some workarounds to preventing it from happening. To prevent it, you just need to let the VM run until the time difference is made up. In my case, when I synchronize the time, it changes by 1 hour, so if I leave the VM running for at least one hour after synchronizing, then it should work. Or you can choose to "save the state" of the VM instead of shutting it down completely. Let me know if you need any help!