
Oracle快照原理及实现总结
Oracle数据库的快照是一个表,它包含有对一个本地或远程数据库上一个或多个表或视图的查询的结果。对于中大型数据库,业务数据库里所有的数据同步到另外一个处理服务器上最佳的选择还是使用SnapShot方式,即快照的方式。
由于工作需要,今天需要将业务数据库里所有的数据同步到另外一个处理服务器上。在做方案的时候,想了很多方法,当然最快的办法还是使用物理热备的方式。
但是我个人认为如果对于中大型数据库(我们的数据库有300G左右)最佳的选择还是使用SnapShot方式,即快照的方式。
Oracle数据库的快照是一个表,它包含有对一个本地或远程数据库上一个或多个表或视图的查询的结果。也就是说快照根本的原理就是将本地或远程数据库上的一个查询结果保存在一个表中。
以下是我建立的Snapshot,目的是从业务数据库上将数据Copy到处理数据库上,是不同的两个服务器之间对数据copy。
第一步:在处理服务器上的Oracle终端,建立database link,业务数据库服务器SID为TEST
create database link TEST_DBLINK.US.ORACLE.COM
connect to AMICOS identified by AMICOS
using 'test'
第二步:在业务数据库上对应的表建立快照日志
Create snapshot log on A_Table
第三步:建立Snapshot 快照名称为:Test_SnapShot
Create snapshot Test_SnapShot
REFRESH COMPLETE START WITH SYSDATE NEXT SYSDATE+1/24
as select * from A_Table@TEST_DBLINK
说明:REFRESH是刷新方法
刷新方式有:COMPLETE和FAST两种,而START WITH是说明开始执行的时间。
Next是下次执行的时间
而AS以后是构成快照的查询方法。
相关的方法:
更改快照
ALTER SNAPSHOT Test_SnapShot
REFRESH COMPLETE START WITH SYSDATE NEXT SYSDATE+1/2
手动刷新快照 在命令界面执行:
EXEC DBMS_SNAPSHOT.REFRESH('Test_SnapShot ','C')
第一个参数是要刷新的快照名
第二个参数是刷新的方式,F----FAST, C---COMPLETE
查看快照最后刷新的日期
SELECT NAME,LAST_REFRESH
FROM ALL_SNAPSHOT_REFRESH_TIMES
最后非常的方案:
1:为需要做Snapshot的表建立Snapshot日志
create snapshot log on t1 with rowid这里使用ROWID建立日记的参数
2:采用Fast的方式建立快照,使用rowid做为参考参数
create snapshot fb_test_b refresh fast with rowid start with sysdate next sysdate+1/1440 as select * from fb_test_b@my_dblink
最好能按照rowid来建立快照。要不然就必须要为表建立Primary Key。
mysql同步数据到hive大部分公司目前都是走的jdbc的方式。 这种方式有两个好处: 也有不好的地方: 这一步最主要的细节是将mysql库的所有binlog数据全部打入一个kafka topic,格式使用json。格式如下: 这一步的主要的细节在于写入到hdfs的结构,以及为什么不直接写入hive。 不写入到hive表的原因在于,binlog的数据结构是不固定的,而hive的结构相对是比较固定的。如果要写入到hive的话,就需要将不同的表的binlog写入到不同的hive表中,这个维护成本太高了。而且spark其实可以直接读取hdfs的json文件,因此直接放hdfs就好了。 写入到hdfs的话,考虑到后续读这个数据是要按照表去读增量数据,所以写入的目录一定是要带日期和表名称的。我这边用的目录结构是这样的: 也就是说要在flink根据数据所属的db、table_name、和日期将数据写入到不同的目录里。 在这一步的处理的过程中遇到了一些比较重要的参数问题。 2.如上所述checkpoint的时间间隔。不仅仅会影响checkpoint的频率,而且会影响hdfs文件的大小,而hdfs文件的大小可能会对hdfs的性能有很大影响。这个值如果太大,就会造成数据延迟太高,如果太小就会造成小文件过多。我这边设置的是5分钟。 细心的看官,这个时候会问了,既然你的目录是分table的,那么每个table每5分钟的binlog数据量是不一样的。对于某些大的mysql表,我们可能每5分钟生成一个文件还能接受。对于一些比较小的表,每五分钟生成一个文件那么文件就会非常小。所以我这边又做了一层的筛选,我把mysql的大的表筛选出来,只同步大的表到hdfs,用以binlog的数据同步。因为本身binlog的方式同步mysql数据为的就是节约mysql的读取压力,而小的表对于不会有太大压力,这些表可以直接通过jdbc的方式去同步。 这个是整个环节里面最复杂的一部分,涉及的细节也比较多。 首先,我们要明确一下总体的思路是什么。总体的思路就是要读取hdfs上的老的历史数据,然后和新的binlog数据合并生成新的快照。 其实这中间还涉及到一些其他的细节,比如mysql表结构变更,或者mysql和hive的数据结构不一致的情况。 另外我们这边还存在多个db的相同的表导入到hive的一张表中的其他问题,我就不赘述了。mysql主从同步的步骤一、主机环境
主机:
master *** 作系统:rhel6.0
IP:172.16.0.100
MySQL版本:5.1.47
从机: www.2cto.com
slave *** 作系统:rhel6.0
IP:172.16.0.200
MySQL版本:5.1.47
二、创建数据库
分别登录master机和slave机的mysql:mysql –u root –p
创建数据库:create database repl
三、master机和slave机的相关配置
1、修改master机器中mysql配置文件my.cnf,该文件在/etc目录下
在[mysqld]配置段添加如下字段
server-id=1
log-bin=mysql-bin
binlog-do-db=repl //需要同步的数据库,如果没有本行,即表示同步所有的数据库
binlog-ignore-db=mysql //被忽略的数据库
在master机上为slave机添加一同步帐号
grant replication slave on *.* to 'replication'@'172.16.0.200' identified by '123456'
重启master机的mysql服务:service mysqld restart
用show master status 命令看日志情况
mysql>show master status
| File | Position | Binlog_Do_DB | Binlog_Ignore_DB |
| log.000003 | 98 | repl | mysql |
1 row in set (0.00 sec)
2、修改slave机中mysql配置文件
同样在[mysqld]字段下添加如下内容
server-id=2 www.2cto.com
master-host=172.16.0.100
master-user=repl
master-password=123456
master-port=3306
master-connect-retry=60
replicate-do-db=repl //同步的数据库,不写本行 表示 同步所有数据库
然后重启slave机的mysql
在slave机中进入mysql
mysql>start slave
mysql>show slave status\G
如果Slave_IO_Running、Slave_SQL_Running状态为Yes则表明设置成功。
这时 再执行show slave status\G
欢迎分享,转载请注明来源:内存溢出
微信扫一扫
支付宝扫一扫
评论列表(0条)