MySQL has nothing to do separate read and write? How to read and write separation of mysql? MySQL master-slave replication principle is valid? How to solve the delay problem mysql master or slave?
High concurrency at this stage, it certainly needs to be done to read and write separation, What do you mean? Because in fact most Internet companies, some websites or app, they are actually reading and writing less. So for this case, is to write a main library, but more from the main library hanging library and read from the library from multiple, it can not support concurrent read more pressure yet?
(1) how to read and write mysql separation?
In fact, very simple, is based on master-slave replication architecture, in short, to engage in a main library, hanging more from the library, and then we just simply write the main library and the main library will automatically sync to the data to go from the library.
(2) MySQL master-slave replication principle is valid?
The main library written binlog change log, and then after connecting from the library to the main library, the library has an IO thread, the main library binlog log to your local copy, written in a relay log. Then there is the library from a SQL thread reads the relay logs from binlog, and then execute binlog contents of the log, that is, in their own local SQL execution once again, so that you can ensure that the data yourself with the main library is the same.
There is a very important point is that the process of database synchronization from the main library data is serialized, that is to say the parallel operation of the main library, the library will be executed from the serial. So this is a very important point, because the implementation of SQL features from the main library as well as a copy of the log from the library serial, under high concurrency scenarios, from the library's main library data would certainly be slower, there is a delay. So often, the data just written to the primary database might not be read, to over tens of milliseconds, or even hundreds of milliseconds to read.
And there's another problem, that is, if the primary database goes down suddenly, and not just the data synchronized to the library, some data may not be from the library, some data may be lost.
So mysql actually in this one there are two mechanisms, a semi-synchronous replication, the main library used to solve data loss problems; a parallel copy, master-slave synchronization to solve the delay problem.
这个所谓半同步复制，semi-sync复制，指的就是主库写入binlog日志之后，就会将强制此时立即将数据同步到从库，从库将日志写入自己本地的relay log之后，接着会返回一个ack给主库，主库接收到至少一个从库的ack之后才会认为写操作完成了。
所谓并行复制，指的是从库开启多个线程，并行读取relay log中不同库的日志，然后并行重放不同库的日志，这是库级别的并行。
- 主从复制的原理
- 主从延迟问题产生的原因
- 主从复制的数据丢失问题，以及半同步复制的原理
- 并行复制的原理，多库并发重放relay日志，缓解主从延迟问题
（3）mysql主从同步延时问题（精华）
线上确实处理过因为主从同步延时问题，导致的线上的bug，小型的生产事故
show status，Seconds_Behind_Master，你可以看到从库复制主库的数据落后了几ms
其实这块东西我们经常会碰到，就比如说用了mysql主从架构之后，可能会发现，刚写入库的数据结果没查到，结果就完蛋了。。。。
所以实际上你要考虑好应该在什么场景下来用这个mysql主从同步，建议是一般在读远远多于写，而且读的时候一般对数据时效性要求没那么高的时候，用mysql主从同步
所以这个时候，我们可以考虑的一个事情就是，你可以用mysql的并行复制，但是问题是那是库级别的并行，所以有时候作用不是很大
所以这个时候。。通常来说，我们会对于那种写了之后立马就要保证可以查到的场景，采用强制读主库的方式，这样就可以保证你肯定的可以读到数据了吧。其实用一些数据库中间件是没问题的。
一般来说，如果主从延迟较为严重
- 分库，将一个主库拆分为4个主库，每个主库的写并发就500/s，此时主从延迟可以忽略不计
- 打开mysql支持的并行复制，多个库并行复制，如果说某个库的写入并发就是特别高，单库写并发达到了2000/s，并行复制还是没意义。28法则，很多时候比如说，就是少数的几个订单表，写入了2000/s，其他几十个表10/s。
- 重写代码，写代码的同学，要慎重，当时我们其实短期是让那个同学重写了一下代码，插入数据之后，直接就更新，不要查询
- 如果确实是存在必须先插入，立马要求就查询到，然后立马就要反过来执行一些操作，对这个查询设置直连主库。不推荐这种方法，你这么搞导致读写分离的意义就丧失了