由于篇幅美观性,将flume实现mysql写入的自定义sink单独一篇文章。
引用sink2的配置
#####发送到本地文件#####
# 订阅Sink
agent2.sinks.k2.type = org.flume.sink.mysql.MysqlSink
agent2.sinks.k2.hostname = 10.19.138.232
agent2.sinks.k2.port = 3306
agent2.sinks.k2.databaseName = internet
agent2.sinks.k2.tableName = i_intelligentcustservice
agent2.sinks.k2.username = username
agent2.sinks.k2.password = password
agent2.sinks.k2.batchSize = 20
吐槽下,IDEA使用MAVEN开发简直不要太好用,
比之前的eclipse好用,应用第三方包,直接在pom.xml里配置,自动下载。
新建项目的话需要设置下mavent仓库的位置。
首先,好久没更新博客,原因是自己太懒,最近在搞接口的开发,本人开发水平属于小白级别。本次需要搭建一个HTTP
POST接口,接受JSON类型的传参,能够发送数据给kafks服务端和写入mysql数据库,原来想自己编写一个JAVA程序来实现,咨询同事后,得知flume可以实现对应的功能。
本文介绍flume的http source配置,配置两个sink,分别发送数据给kafka和mysql。
1、####配置/etc/hosts,添加kafka和zookeeper地址
##(kafka:TCP 6667 zookeeper:TCP 2181
x3/x4 : TCP/UDP 88)
##kafka
11.11.11.51 c6h551 h551
##zookeeper
11.11.11.201 c6x1 x1
2、#####
设置环境变量
(又一年马上要结束了)
SPM是继SQLPROFILE出现的又一个绑定执行计划的方法,是一种主动的稳定执行计划的手段,能够保证只有被验证过的执行计划才会启用,既能够主动地稳定执行计划,又保留了继续使用新的执行计划效率可能更高的执行计划的计划。
SPM通过SQL
PLAN
BASELINE实现执行计划的管理,代表一个执行计划,视图DBA_SQL_PLAN_BASELINES的字段ENABLED和ACCEPTED均为YES时,才会被使用。
通过两种方法产生
最近在处理2pc问题时,进行了些许研究,想在这里记录总结一下,也是好久没有更新博客,
一直也想不起来进行总结,以后希望能够坚持写作,不往同志们的关注。
ORACLE分布式事务
数据库分布式事务是对两个或多个数据库进行修改,包含了跨越多个节点的DML语句。分布式事务确保原子性,事务内的所有操作不能一起提交就只能一起回滚。
分布式事务和远程事务是不同的,远程事务包括一个或多个DML操作,只是操作一个相同的数据库节点,
例如:
- 分布式事务:
&
(同志们,好久不见。)
本文章内容主要针对灰度发布针对数据库端表级别不同版本对应用的不兼容性问题。
在11gR1之前,当业务系统需要升级的时候,我们常常需要停下,从而保证版本的一直性和访问的连续性,对于一些APP变更频繁但又不允许经常停应用的IT系统,
无法做到兼顾,从11gR2开始,Oracle引入edition(版本)的概念,以实现app的online upgrade.
同时该特性允许pre-upgrade application and the post-upgrade application并存,
等我们确认post-upgrade app没问题的时候再把pre-upgrade app切换下来,
在这期间整个APP的访问是不受影响的.从而可以最大程度的减少application down
time.实际上这个特性,在11gR1中已经提供了,通过隐藏参数来控制_edition_based_redefinition
11gR1中该参数默认是false. 11gR2中,该参数已经被废弃,默认为启用。
edition(版本)
由于调整数据库主机时间导致的数据库实例宕机重启的故障。
应用反应主机时间与正确的时间相差有8分多钟,影响了正常的业务,
登录发现主机的NTP服务是开启的,查看NTP同步状态:
remote
refid st t when poll reach delay
offset jitter
================================================================
*172.xx.xx.xx 139.114.32.135 2 u 22
64 377 0.180 0.051 0.028
可以看到offset是0.051s,基本没有延迟,那么问题就出在Ntpserver的时间存在不准确的可能,通过主机工程师
查看,果然server端存在延迟的情况。