We use master and slave for better performance. Chat will not be automatically running on slave when master is down. You need to promote slave to master as below.
A Cron Job can be written to ping the Master Redis node continuously. This will not be a drain on Redis as Redis is built for high request-response setups. Whenever this ping fails, this Redis Master should be taken out and one of the slaves should be promoted as the master. Also, there should be a re-pointing of the DNS entry that was pointing to the old Redis master to this new Redis master. All of this will be transparent to the Chat or Co-browse setup.
In Pega Chat Cloud environment, we have code in place which will take care of the DNS remapping. Whenever the Redis goes down, we intentionally crash the server. We suggest that our Node Applications be running with the forever(https://www.npmjs.com/package/forever) node module. This ensures that if the server crashes the application is restarted. This coupled with our intentional crashing will ensure that the new DNS is resolved, thereby bringing the new Redis master into use.
To elaborate Srikanth's reply : You can have a cron job running which will periodically check the health of the redis master, now suppose the master goes down, the cron job comes to know. At this point of time chat server will crash as redis connection is interrupted and now you need to promote the slave to act as master, but the URL of the slave in your case 'slave.xx.xx' is not changed , so the chat server cannot connect to it. You need to remap "slave.xx.xx" to "master.xx.xx." using some APIs provided by your DNS mapping provider. After the remapping is done the chat server will connect to the new redis master.