Seperate Redis databases

[rhammer2003]

Hello All,

Is it possible to run separate Redis Database instances? if so what do I need to do? I would like to setup a second server running a different map for my arma3 epoch.

[Darth_Rogue]

Just have a separate folder for both Redis instances. In the config for Redis set the second server to use a different port and make the port setting in epoch config.ini to match.

[rhammer2003]

this is what I currently have in my redis.conf, where do I set the port number here?

bind 127.0.0.1
maxmemory 4gb
save 900 1
save 300 10
save 60 1000
requirepass

[Angrygargamel]

no need to start another redis server for another instance...

you also wouldnt start another mysql server for a 2nd database... would you? ;)

 

just change your
InstanceID = NA123 to another instance id
in @epochhive\EpochServer.ini and you have another instance

 

or change

DB = 0 to a higher number

in @epochhive\EpochServer.ini and you have another database
 

[Richie]

What i do is have a seperate installation and specify the port in both redis.conf.

So my original redis.conf has

bind 127.0.0.1
port 6379
maxmemory 2gb
save 900 1
save 300 10
save 60 1000
requirepass My_Secret_Pass

My 2nd instance of redis.conf has

bind 127.0.0.1
port 6479
maxmemory 2gb
save 900 1
save 300 10
save 60 1000
requirepass My_Other_Secret_Pass

Then in the epochserver.ini they have a seperate instance ID although i don't think that's needed, does no harm to change it though and a unique DB ID for both :) then launch both instances of Redis

[Darth_Rogue]

no need to start another redis server for another instance...

you also wouldnt start another mysql server for a 2nd database... would you? ;)

 

just change your

InstanceID = NA123 to another instance id

in @epochhive\EpochServer.ini and you have another instance

 

or change

DB = 0 to a higher number

in @epochhive\EpochServer.ini and you have another database

 

 

 

There are circumstances where you would want a separate Redis server running.  If you run multiple servers it's not smart to have both of them using the same database with Redis.  Say you have a scripter come into the server and wreak havoc and you have to roll back the database.  If you're using one Redis server for both game servers, then you'll be rolling back the database for BOTH servers, since they both use the same db server.  Granted, they are on separate instances within the db, but with Redis, every instance is contained within the same dump.rdb file.  So to restore a backup for one is to restore a backup for both.  

 

SQL is different in that despite the fact that you have one SQL server running, it has multiple databases and they are all separate and independent from each other.  So if you need to wipe one and roll it back it doesn't affect the others.  Redis isn't built that way.  With Redis, you roll back one, you roll back them all, which can have some very undesirable affects.  Here again, this is another reason why, in my opinion, we should be running SQL for Epoch.

[Floyd]

Has the new version done away with the massive Qfork file? Please say yes.....(or have I fubar'd something?).

All I have now is the .rdb file.

[Darth_Rogue]

I never noticed that but you're right.  I've been using the updated version on my test server for a few days now and it seems to be working alright.  The only issue I've had is it not saving my backpack items sometimes.  Not sure if that's just me or there's a bad file in my Epoch someplace though.  So I wouldn't try to pin it on the Redis update just yet.  

[Angrygargamel]

There are circumstances where you would want a separate Redis server running.  If you run multiple servers it's not smart to have both of them using the same database with Redis.  Say you have a scripter come into the server and wreak havoc and you have to roll back the database.  If you're using one Redis server for both game servers, then you'll be rolling back the database for BOTH servers, since they both use the same db server.  Granted, they are on separate instances within the db, but with Redis, every instance is contained within the same dump.rdb file.  So to restore a backup for one is to restore a backup for both.  

 

SQL is different in that despite the fact that you have one SQL server running, it has multiple databases and they are all separate and independent from each other.  So if you need to wipe one and roll it back it doesn't affect the others.  Redis isn't built that way.  With Redis, you roll back one, you roll back them all, which can have some very undesirable affects.  Here again, this is another reason why, in my opinion, we should be running SQL for Epoch.

and thats why i prefer mysql databases instead of this redis shit...

i really dont see why this crap should be so much better than mysql...

[Darth_Rogue]

Agreed.  I'd say eventually there will be more tool for Redis released by the community.  I'd like to at least see some kind of pull or merge tools where you can delete specific info and not whole keys or merge two different databases together into one.  

[Vaprz]

 Here again, this is another reason why, in my opinion, we should be running SQL for Epoch.

 

Redis is a disaster. We've already run into two situations in the last 3 months where Redis failed to complete a disk save and choked, forcing us to use AOF for persistence - which in turn negates all the performance benefits of using a lightweight solution like Redis in the first place. Diskless replication would be another option to mitigate a catastrophic situation, but that is not available in the current windows port. For now we disk write then replicate over the latest dump.rdb to a backup slave and keep an AOF file running on the primary redis instance, with daily BGREWRITEAOF to keep it at optimal size. 

 

I'd kill for a mysql/mariadb SQL database system at this point. 

 

Redis is great for flushable data as a web backend, but not to store stuff you actually want to keep.