[question] I am receiving this error when I connected Aedes to Redis as persistent

[mushroomwithegg]

I encountered this issue then I tried to use emqx/emqtt-bench for benchmark and run sub

I am using redis-ha as my persistence and emitter.

(node:1) UnhandledPromiseRejectionWarning: ReplyError: READONLY You can't write against a read only replica.                                                                                                                                  
    at parseError (/usr/local/lib/node_modules/aedes-cli/node_modules/redis-parser/lib/parser.js:179:12)                                                                                                                                      
    at parseType (/usr/local/lib/node_modules/aedes-cli/node_modules/redis-parser/lib/parser.js:302:14)                                                                                                                                       
(node:1) UnhandledPromiseRejectionWarning: Unhandled promise rejection. This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). To terminat
e the node process on unhandled promise rejection, use the CLI flag `--unhandled-rejections=strict` (see https://nodejs.org/api/cli.html#cli_unhandled_rejections_mode). (rejection id: 4819)

[robertsLando]

I don't think that's an issue with aedes-cli, maybe it's sometinh related to aedes-persistence redis.

Could you paste here your config.js file? Could be something related to: https://github.com/moscajs/aedes-persistence-redis/pull/58 ?

[mushroomwithegg]

something like this:

module.exports = {
  // SERVERS
  protos: ['tcp'],
  host: '0.0.0.0',
  port: 1883,
  wsPort: 3000,
  wssPort: 4000,
  tlsPort: 8883,
  key: null,
  cert: null,
  rejectUnauthorized: false,
  // AUTHORIZER
  credentials: '/data/credentials.json',
  // AEDES
  brokerId: 'aedes-cli',
  concurrency: 100,
  queueLimit: 42,
  maxClientsIdLength: 23,
  heartbeatInterval: 60000,
  connectTimeout: 30000,
  stats: true,
  statsInterval: 5000,
  // PERSISTENCES
  persistence: {
    name: 'redis',
    options: {
      host: 'redis'
      port: 6379,
      family: 4,
      db: 0,
      maxSessionDelivery: 1000,
      packetTTL: function (packet) { 
        return 10 
      }
    }
  },
  mq: {
    name: 'redis',
    options: {
      host: 'redis'
      port: 6379,
      family: 4,
      db: 0,
      maxSessionDelivery: 1000,
      packetTTL: function (packet) { 
        return 10 
      }
    }
  },
  verbose: false,
  veryVerbose: false,
  noPretty: false
}

[robertsLando]

@mcollina

[mushroomwithegg]

Additional info, I tried this setup in kubernetes so the redis I used is stable/redis-ha from helm.

[robertsLando]

I think aedes-persistence-redis doesn't support Redis Clusters

[mushroomwithegg]

Any plan to implement it? Because I saw this PR in aedes-persistence-redis repository: https://github.com/moscajs/aedes-persistence-redis/pull/58

[mcollina]

I would not recommend using aedes-redis-persistence with redis cluster due to how pubsub works (it's a broadcast in the cluster) - it won't scale well.

Anyway, I've never tried. A PR that add some tests for Redis Cluster and fixes the relative bug would is always welcome.

[robertsLando]

@mcollina Actually there is an open pr for Redis clusters support, it's missing a unit test. If I find some time I could work on that

[mushroomwithegg]

@mcollina , can you please elaborate more about having redis cluster together with an mqtt broker? Sorry, I am not that familiar with pubsub and why there will be an issue.

Because the setup that I have in mind, and what helm redis-ha is, is a redis cluster with master slave relationship. So all the data will be put to master and the slave will just make sure that they are in sync with the master and once master is down, they can assume the role as master and receive all the traffic. Do I have it right?

[mcollina]

https://redislabs.com/wp-content/uploads/2018/04/Redis-Day-TLV-2018-Scaling-Redis-PubSub.pdf shows the problem of using Redis PubSub with Redis Cluster - the more node you add, the slower it would get. All details of this can be found through a google search.

Note that https://github.com/DandyDeveloper/charts/tree/master/charts/redis-ha is not a Redis cluster, but a more traditional Sentinel deployment. You should be able to use this with Aedes.

[mushroomwithegg]

I see. I'll read the cluster pdf and I yep, you are right. Thank you for explaining it.

But the problem is that it is already my setup. I am using that repository (https://github.com/DandyDeveloper/charts/tree/master/charts/redis-ha) currently and I received some warning.

UnhandledPromiseRejectionWarning: ReplyError: READONLY You can't write against a read only replica.

You can check the complete warning in my first comment in this issue.

[robertsLando]

https://github.com/moscajs/aedes-persistence-redis/pull/76

[robertsLando]

aedes-cli@0.4.2 updated with latest redis and mongo persistences

[mushroomwithegg]

@robertsLando @mcollina , I figured it out. I got a hint from mcollina's reply by defining the difference between sentinel and cluster. I am so sorry. It is my fault. I enabled haproxy in the values.yaml file for stable/redis-ha and it does the job. I no longer received the error when I am subscribing to the broker. Thanks so much for the effort shown.