Does memcached support replication with fail over?. In some posts I've read they mentioned that there is no connection between the nodes and they are blind, but in some they are talking about replication.
No. Memcache does not support replication or persistence. Also its true that there is no connection between the nodes. And this simplicity is the reason that it is one of the fastest caches.
It is usually the client that handles multiple nodes and decides which key belongs to which server.
There are some patches available to enable replication on memcache. You can take a look at Repcached
it should be pointed out that newer versions of memcached do support replication.
Options:
MEMCACHED_BEHAVIOR_NUMBER_OF_REPLICAS
session_number_of_replicas
can both be investigated.
session_number_of_replicas can be used with sess_binary=1 and sess_consistent_hash=1 to repicate sessions over memcached nodes.
MEMCACHED_BEHAVIOR_NUMBER_OF_REPLICAS in conjunction with MEMCACHED_BEHAVIOR_REMOVE_FAILED_SERVERS can be used to create cache persistence (not to be confused with data persistence as it is still cache) with failover.
Related
We want to create a MongoDB shard (v. 2.4). The official documentation recommends to have 3 config servers.
However, the policies of our company won't allow us to get 3 extra servers for this purpose. Since we have already 3 application servers (1 web node, 2 process nodes) we are considering to put the configuration servers in the same application servers, with the mongos. Availability is not critical for us.
What do you think about this configuration? Can we face some problem or is it discouraged for some reason?
Given that Availability is not critical for your use case, I would say it should be fine to place the config servers in the same application servers and mongos.
If one of the process nodes is down, you will lose: 1 x mongos, 1 application server and 1 config server. During this down time, the other two config servers will be read-only , which means there won't be balancing of shards, modification to cluster config etc. Although your other two mongos should still be operational (CRUD wise). If your web-node is down, then you have a bigger problem to deal with.
If two of the nodes are down (2 process nodes, or 1 web server and process node), again, you would have bigger problem to deal with. i.e. Your applications are probably not going to work anyway.
Having said that, please consider the capacity of these nodes to be able to handle a mongos, an application server and a config server. i.e. CPU, RAM, network connections, etc.
I would recommend to test the deployment architecture in a development/staging cluster first under your typical workload and use case.
Also see Sharded Cluster High Availability for more info.
Lastly, I would recommend to check out MongoDB v3.2 which is the current stable release. The config servers in v3.2 are modelled as a replica set, see Sharded Cluster config servers for more info.
I'm not exactly a DBA, so I would appreciate easy to understand responses. I have to provide replication to our DB and pgpool seems more convenient because if one postgresql instance fails, the clients are not required to change anything to keep on working, right? So, in this case, makes more sense to use pgpool, but the configuration part seems (to me) a lot more complicated and confusing. For instance, do I need to set up WAL on both postgresql servers? Or this is only needed if I want to set up postgresql replication? The more I try to get an answer to these questions, the less clear it becomes. Maybe I forgot how to google...
The built-in replication, provided by PostgreSQL itself, includes streaming replication, warm standby, and hot standby. These options are based on shipping Write-Ahead Logs (WAL) to all the standby servers. Write statements (e.g., INSERT, UPDATE) will go to the master, and the master will send logs (WALs) to the standby servers (or other masters, in the case of master-master replication).
pgpool, on the other hand, is a type of statement-based replication middleware (like a database proxy). All the statements actually go to pgpool, and pgpool forwards everything to all the servers to be replicated.
One big disadvantage with pgpool is that you have a single point of failure; if the server running pgpool crashes, your whole cluster fails.
The PostgreSQL documentation has some basic info on the various types of replication that are possible: https://www.postgresql.org/docs/current/different-replication-solutions.html
We're considering Slony and PGPool as alternatives to handle failover in our application -and it seems like since we're gonna need at least two DB servers, we could take advantage of load balancing too-
Under which circumstances Slony is better than PGPool and viceversa?
This is anecdotal, so take it with a grain of salt.
PGPool and streaming WAL replication (with hot standby or not) works the way database replication ought to. Your application doesn't need to know anything about replication or whether it is part of a cluster or whatnot, it just talks to the database as it would any other. Streaming replication is robust, and has the ability to fail back to WAL shipping if streaming breaks. PGPool makes managing this process easy and gives good heartbeats and monitoring info.
Slony, on the other hand, is an administrative tar-pit, which needs to add trigger functions and numerous other objects to your database to work. Furthermore, Slony doesn't (easily) support the ability to replicate schema changes (DDL) in the same way it replicates ordinary insert/update/delete type operations (DML). Taken as a whole, these characteristics mean that, in many cases, your application needs to have special cases to handle Slony's eccentricities. In my opinion, that's bad: the application shouldn't have to be aware of/make changes to deal with the database replication solution that it runs on. I spent the better part of a year hacking Slony to work as a stable replication solution, and eventually came to the conclusion that it's a bad idea/bad replication mechanic implemented in an obtuse, illegible way, that is anything but stable or enterprise-ready. EDIT: as of PostgreSQL 9.3 you can install triggers (which Slony uses to detect changes) on DDL objects, which might allow Slony to replicate more aspects of a database.
That said, Slony does do two things better than streaming replication (administered via PGPool or no):
Slony allows per-table or per-database replication. Streaming replication only permits the replication of an entire Postgres instance. If that kind of granularity is important to you, you might want Slony.
Slony allows cascading (master -> slave -> slave) replication. Streaming replication only allows one level. EDIT: This is now supported in PostgreSQL native streaming replication, as of Postgres version 9.2.
At literally everything else, streaming replication is better and more stable.
But you're not just asking about streaming replication: PGPool does a great deal more than that. It allows the balancing of read and write loads between read-only slave databases and masters, and the implementation of backup plans, as well as a whole host of other things. Especially when compared to Slony's arcane command syntax and godawful administration scripts, PGPool wins in nearly every instance.
With regards to failover specifically, PGPool has heartbeat monitors and the ability to automatically route database traffic in a cluster. Slony only has a "fail over to slave now" command, leaving all of the monitoring and app-side routing up to you.
TL;DR: PGPool good. Slony bad.
with memcache, can you add/remote nodes on the fly?
if a node goes down, does it redistribute automatically?
Memcached daemons themselves do not have any knowledge of one another. Node management is handled completely at the client level. Most client implementations rely on consistent hashing of keys to determine which server in a ring the values reside on. Many of the client libraries will failover to other nodes in the ring when a node becomes unavailable.
I am not aware of any memcached clients that attempt to provide clustering or high availability.
No, But you can try Hazelcast. Also it doesn't state yet with version 1.8.5 it does support memcache protocol. The next release will have all documentation about it.
So you can replace your Memcached servers with Hazelcast. And Hazelcast does support adding and removing nodes on the fly.
Scenario
Multiple application servers host web services written in Java, running in SpringSource dm Server. To implement a new requirement, they will need to query a read-only PostgreSQL database.
Issue
To support redundancy, at least two PostgreSQL instances will be running. Access to PostgreSQL must be load balanced and must auto-fail over to currently running instances if an instance should go down. Auto-discovery of newly running instances is desirable but not required.
Research
I have reviewed the official PostgreSQL documentation on this issue. However, that focuses on the more general case of read/write access to the database. Top google results tend to lead to older newsgroup messages or dead projects such as Sequoia or DB Balancer, as well as one active project PG Pool II
Question
What are your real-world experiences with PG Pool II? What other simple and reliable alternatives are available?
PostgreSQL's wiki also lists clustering solutions, and the page on Replication, Clustering, and Connection Pooling has a table showing which solutions are suitable for load balancing.
I'm looking forward to PostgreSQL 9.0's combination of Hot Standby and Streaming Replication.
Have you looked at SQL Relay?
The standard solution for something like this is to look at Slony, Londiste or Bucardo. They all provide async replication to many slaves, where the slaves are read-only.
You then implement the load-balancing independent of this - on the TCP layer with something like HAProxy. Such a solution will be able to do failover of the read connections (though you'll still loose transaction visibility on a failover, and have to start new transaction on the new slave - but that's fine for most people)
Then all you have left is failover of the master role. There are supported ways of doing it on all these systems. None of them are automatic by default (because automatic failover of a database master role is really dangerous - consider the situation you are in once you've got split brain), but they can be automated easily if the requirement needs this for the master as well.