读写分离数据一致性解决方案
oracle快照过旧解决办法？
oracle快照过旧解决办法？
用户user1对表进行了更新操作,用户user2在user1还没有进行提交前读表中数据,而且是大批量的读取(打个比方:耗时3分钟)而在这3分钟内user1进行了提交操作,那又会产生什么影响呢?这个时候怎么保证读写一致性呢?这个时候DBMS就要保证有足够大的undo表空间来存放修改前的数值,,以保证user2读取的数据是修改前的一致数据.然后下次再读取时候就是更新后的数据了.
ora-01555快照过旧就是因为undo空间不够大，其中一部分undo数据被覆盖了，用户无法获得修改前的数据。
undo数据分为三种：
活动的undo：未提交事务的undo数据，这些undo数据永远不能覆盖，用于回滚rollback事务。
过期的undo：已提交事务的undo数据，这些undo数据可以覆盖。
未过期的undo：事务已提交，但事务提交前，有些查询正在进行，它要读取的是提交前的数据，这部分数据就是未过期数据。如果这部分undo数据被覆盖了，就会发生ora-01555错误。
一个解决方法是，指定undo表空间参数UNDO_TABLESPACE，并将undo空间管理方法设置成自动扩展：UNDO_MANAGEMENTAUTO。
这种方法可能产生的结果是：
因为undo表空间装了太多未过期（unexpired）的undo数据，新的transaction无法向其中写入undo数据，这时transaction就会发生ORA-30036错误。
mysql如果出现主从数据不一致情况怎么弄？
1.网络的延迟由于mysql主从复制是基于binlog的一种异步复制，通过网络传送binlog文件，理所当然网络延迟是主从不同步的绝大多数的原因，特别是跨机房的数据同步出现这种几率非常的大，所以做读写分离，注意从业务层进行前期设计。
2.主从两台机器的负载不一致由于mysql主从复制是主数据库上面启动1个io线程，而从上面启动1个sql线程和1个io线程，当中任何一台机器的负载很高，忙不过来，导致其中的任何一个线程出现资源不足，都将出现主从不一致的情况。
_allowed_packet设置不一致主数据库上面设置的max_allowed_packet比从数据库大，当一个大的sql语句，能在主数据库上面执行完毕，从数据库上面设置过小，无法执行，导致的主从不一致。
自增键开始的键值跟自增步长设置不一致引起的主从不一致。
异常宕机情况下，如果未设置sync_binlog1或者innodb_flush_log_at_trx_commit1很有可能出现binlog或者relaylog文件出现损坏，导致主从不一致。
本身的bug引起的主从不同步。
7.版本不一致，特别是高版本是主，低版本为从的情况下，主数据库上面支持的功能，从数据库上面不支持该功能。