why all writes must go to the master and why writing to a slave makes no sense?

http://www.pcpro.co.uk/realworld/355477/understanding-the-nosql-movement:

However, all writes must go to the master, because the data flow is one-way from master to slaves, and writing to a slave makes no sense.

I'm having trouble understanding that statement. From my limited understanding, I just can't see why does this limitatio开发者_运维知识库n exists. Isn't there some way for the slave to "talk" to the master so a user could simply write to a slave, and the slave will then inform the master of the write.. no?

---

Simply put, because you lose consistency. what do you do when a write to the slave and a simultaneous write to the master conflict? Either one or the other update will be lost, or if you detect the conflict, what do you do then?

Normally, you want your database to exhibit the ACID properties. If you want that, then with multiple servers accepting writes (that's really the definition of a master), you're into the multimaster scenarios that the article you refer to does discuss, and the scalability issues that come with that (see Distributed Transactions for a bit more detail)

---

The term "master" in this sense means "owner" - the authoritative copy of the data. Slaves are replicas which can be used to distribute the load. (Typically there are multiple slaves per master)

So by definition, any node taking writes becomes a "master". There are many systems which support "multi-master" configurations, and these are typically more complex that single-master systems because the masters need to maintain consistency between themselves.

I wrote a post explaining this in more detail here

---

The definition of master-slave replication is that the master handles all writes, and the slave only handles reads, receiving a stream of updates from the master. If both servers handle writes, this falls under the definition of 'master-master replication', which comes with its own host of data consistency issues.