Anyone know if Minimongo could be used in a plugin to enable redis-style caching to a full mongodb instance? The redis (live) to mongodb (persist) route looks daunting...
To be honest, server migration does take time that I do not have for now (especially after the crash of this week), in the meantime I need to keep OVH because my server is hosting different applications that I can't move at the same time. So of course I will try it for new application or test but for now my dirty fix would be upgrading redis (I just compiled latest 3.0.5, it's ok) or upgrade nodeBB to another db, but seems I need to pay for this one.
@Charly86 it does not makes a lot of sense to compile a new version of Redis, which also has its difficuilties with OVH. If you want I can assist you, just PM me.
That's just silly theory. I have been using the same 32 GB dedicated OVH server for several years and I've never had any RAM or any other issues with the server.
@Charly86 thats interesting. I would suspect OVH to be responsible for the failure. It could be the case that their RAM has certain problems. Maybe try a setup on Kimsufi (OVH - dedicated servers) and see if it occurs again.
@Pilvinen sure? OVH is known for having its difficuilties here and there. The other question then would also be why I didn't lost my data.
And why all of you 3 (at least 2), who are using OVH have the same problem.
You said it all you've got a "dedicated server", I've got a VPS which is slightly different because all resources are shared with other customers VM (on same physical server), so of course in your case it make no sense, but in mine, I'm not sure this is so silly
But it seems like the same issue. Redis database gets destroyed randomly, but rarely.
correct, I forgot you had the issue
@Pilvinen well. Then you have to think what can cause Redis to destroy its database.
Corruption, seems like the most logical case.
And as Redis does not stores the database on your HDD it can only be the RAM.
Also the fact that both of you use OVH makes it a bit strange.
I agree, upgrading to 3.0.5 will certainly not solve the issue, but does not hurt to try
@AOKP Well, it persists it to HDD on shutdown. Maybe the server was forced shutdown, and redis didn't have time to save, or the save corrupted the db?
If it helps clarifying the issue - when I noticed the forum had crashed and database was gone I tried to use redis-cli to do a proper shutdown - I connected which worked fine and tried running commands - And I got no response to the commands like Redis normally gives.
In my case it's saved every 5 minutes onto disk, so I should have lost only 5 minutes, except if as you says, it saved corrupted db.
297] 08 Nov 02:19:36.116 * Background saving terminated with success  08 Nov 02:24:37.088 * 10 changes in 300 seconds. Saving...  08 Nov 02:24:37.091 * Background saving started by pid 4508  08 Nov 02:24:37.114 * DB saved on disk  08 Nov 02:24:37.115 * RDB: 0 MB of memory used by copy-on-write  08 Nov 02:24:37.192 * Background saving terminated with success  08 Nov 02:29:38.091 * 10 changes in 300 seconds. Saving...  08 Nov 02:29:38.092 * Background saving started by pid 4511  08 Nov 02:29:38.110 * DB saved on disk  08 Nov 02:29:38.110 * RDB: 0 MB of memory used by copy-on-write  08 Nov 02:29:38.193 * Background saving terminated with success  08 Nov 02:34:39.034 * 10 changes in 300 seconds. Saving...  08 Nov 02:34:39.035 * Background saving started by pid 4514  08 Nov 02:34:39.059 * DB saved on disk
after corruption I connected to redis without issue but database structure was
Why don't you try AOF instead of RDB?
It can save every second, without any certain performance loss. The only disadvantage is that it uses more disk space.
yeah no problem for me using AOF, I need to set it in redis.conf ?
I'll check this thanks
Another idea would be to configure a cronjob running every X minutes, copying the database.
cp -R /var/lib/redis.rdb /root
Yeah I've already put a backup into /etc/cron.hourly as a fix
@pitaj My version is this:
web02:~$ redis-server -v
Redis server v=3.0.3 sha=00000000:0 malloc=jemalloc-3.6.0 bits=64 build=e1e08a07153b9ea1