5
15
新手上路
Cache V.S MySQL读写分离 由于从开发和维护的难度考虑,引入缓存会引入复杂度,要考虑缓存数据一致性,穿透,防雪崩等问题,并且也多维护一类组件。所以推荐优先采用读写分离,扛不住了再使用Cache。
主库宕机后,binlog丢失导致的主从数据不一致也只能手动恢复。
推荐该方案,因为足够简单,不过可能造成单条消息较大,从而增加消息发送的带宽和时间。
线程A把Cache数据更新为1 另一个线程B把Cache数据更新为2 然后线程B又更新DB数据为2 线程A再更新DB数据为1
主从的延迟时间预警,那如何通过哪个数据库中的哪个指标来判别?在从从库中,通过监控show slave status\G命令输出的Seconds_Behind_Master参数的值判断,是否有发生主从延时。这个参数值是通过比较sql_thread执行的event的timestamp和io_thread复制好的 event的timestamp(简写为ts)进行比较,而得到的这么一个差值。但如果复制同步主库bin_log日志的io_thread线程负载过高,则Seconds_Behind_Master一直为0,即无法预警,通过Seconds_Behind_Master这个值来判断延迟是不够准确。其实还可以通过比对master和slave的binlog位置。
若大量订单,通过userId hash到不同库,对前台用户订单查询有利,但后台系统页面需查看全部订单且排序,SQL执行就很慢。这该怎么办呢?
您需要 登录 才可以下载或查看,没有账号?立即注册
上一篇: 说说为什么要做数据库拆分
下一篇: MySQL innoDB 间隙锁产生的死锁问题
举报 回复 使用道具 分享