haproxy: All content tagged as haproxy in NoSQL databases and polyglot persistence
I haven’t got to learn Erlang yet, so I’m mostly bookmarking OJ’s 3 part tutorial for future read:
- ☞ Part 1
In Part 1 of the series we covered the basics of getting the development environment up and running. We also looked at how to get a really simple ErlyDTL template rendering
- ☞ Part 2
There are a few reasons this series is targeting this technology stack. One of them is uptime. We’re aiming to build a site that stays up as much as possible. Given that, one of the things that I missed in the previous post was setting up a load balancer. Hence this post will attempt to fill that gap.
- ☞ Part 3
In this post we’re going to cover:
- A slight refactor of code structure to support the “standard” approach to building applications in Erlang using OTP.
- Building a small set of modules to talk to Riak.
- Creation of some JSON helper functions for reading and writing data.
- Calling all the way from the Webmachine front-end to Riak to extract data and display it in a browser using ErlyDTL templates.
Original title and link: Tutorial: Developing in Erlang with Webmachine, ErlyDTL, and Riak (NoSQL databases © myNoSQL)
☞ A simple notice about a short scheduled GitHub downtime resulted in a great dialog about how to perform zero downtime Redis upgrades. The following approaches were suggested:
- using Redis replication (i.e.
SLAVE OF) to move existing data from the old Redis to the new Redis and haproxy to transparently pass client requests to the Redis instance (initially to the existing version and once replication completed to the new one)
- Leave the old redis version running on, say, redis:6379.
- Install and start a new redis on redis:6380 with a different dump file location.
- Execute SLAVE OF redis 6379 against redis:6380. Wait for first SYNC to complete.
echo "enable server redis/redis-6380" | socat stdio unix-connect:/var/run/haproxy/admin.sock
echo "disable server redis/redis-6379" | socat stdio unix-connect:/var/run/haproxy/admin.sock
- Execute SLAVE OF no one on redis:6380.
- Execute SHUTDOWN on redis:6379.
- using virtual IPs instead of haproxy
A more generic idea shared in the comment thread was to architect the solution so that the overall system would continue to work even if some subsystems are temporarily down. If you think in terms of the CAP theorem, this idea could be translated as a system that is AP at all times.
While writing this post I remembered reading about a ☞ solution based on node.js. node.js would be used to proxy requests until it is notified that the back system goes down. It would temporarily hold incoming connections until it would be notified again that the back system is resuming.
Any other ideas?