可以用触发器实现,如果A、B数据库的数据都会变化的话,那么两边都要建立触发器,比如A库a表上建立触发器(增删改都需要,只举插入触发器的例子)
select@字段1=字段1,@字段2=字段2,@主键=主键
frominserted
ifexists(selectfromBdboawhere主键=@主键)
begin
--如果有重复的数据怎么处理?是报错,还是不做任何处理直接return,在这里写语句
end
insertintoBdboa(字段1,字段2)
values(@字段1,@字段2)
如果不在同一台服务器上,用触发器就不太保险,因为如果其中一台服务器出了故障,对表的增删改 *** 作都会出问题,除非你能保证两台服务器都能运行正常,或者可以在很短的时间内排除故障。
最简单的减少slave同步延时的方案就是在架构上做优化,尽量让主库的DDL快速执行。还有就是主库是写,对数据安全性较高,比如sync_binlog=1,innodb_flush_log_at_trx_commit = 1 之类的设置,而slave则不需要这么高的数据安全,完全可以讲sync_binlog设置为0或者关闭binlog,innodb_flushlog也可以设置为0来提高sql的执行效率。另外就是使用比主库更好的硬件设备作为slave。mysql-563已经支持了多线程的主从复制。原理和丁奇的类似,丁奇的是以表做多线程,Oracle使用的是以数据库(schema)为单位做多线程,不同的库可以使用不同的复制线程。
sync_binlog=1
This makes MySQL synchronize the binary log’s contents to disk each time it commits a transaction
默认情况下,并不是每次写入时都将binlog与硬盘同步。因此如果 *** 作系统或机器(不仅仅是MySQL服务器)崩溃,有可能binlog中最后的语句丢 失了。要想防止这种情况,你可以使用sync_binlog全局变量(1是最安全的值,但也是最慢的),使binlog在每N次binlog写入后与硬盘 同步。即使sync_binlog设置为1,出现崩溃时,也有可能表内容和binlog内容之间存在不一致性。如果使用InnoDB表,MySQL服务器 处理COMMIT语句,它将整个事务写入binlog并将事务提交到InnoDB中。如果在两次 *** 作之间出现崩溃,重启时,事务被InnoDB回滚,但仍 然存在binlog中。可以用--innodb-safe-binlog选项来增加InnoDB表内容和binlog之间的一致性。(注释:在MySQL 51中不需要--innodb-safe-binlog;由于引入了XA事务支持,该选项作废了),该选项可以提供更大程度的安全,使每个事务的 binlog(sync_binlog =1)和(默认情况为真)InnoDB日志与硬盘同步,该选项的效果是崩溃后重启时,在滚回事务后,MySQL服务器从binlog剪切回滚的 InnoDB事务。这样可以确保binlog反馈InnoDB表的确切数据等,并使从服务器保持与主服务器保持同步(不接收 回滚的语句)。
innodb_flush_log_at_trx_commit (这个很管用)
抱怨Innodb比MyISAM慢 100倍?那么你大概是忘了调整这个值。默认值1的意思是每一次事务提交或事务外的指令都需要把日志写入(flush)硬盘,这是很费时的。特别是使用电 池供电缓存(Battery backed up cache)时。设成2对于很多运用,特别是从MyISAM表转过来的是可以的,它的意思是不写入硬盘而是写入系统缓存。日志仍然会每秒flush到硬 盘,所以你一般不会丢失超过1-2秒的更新。设成0会更快一点,但安全方面比较差,即使MySQL挂了也可能会丢失事务的数据。而值2只会在整个 *** 作系统 挂了时才可能丢数据。
NTP时间同步服务器 主要偏重于NTP时间同步功能
北斗时间同步服务器 主要偏重于北斗卫星时间来源
GPS时间服务器跟北斗时间同步服务器一样也偏重于时间来源是GPS卫星。
目前计算机网络中各主机和服务器等网络设备的时间基本处于无序的状态。随着计算机网络应用的不断涌现,计算机的时间同步问题成为愈来愈重要的事情。以Unix系统为例,时间的准确性几乎影响到所有的文件 *** 作。 如果一台机器时间不准确,例如在从时间超前的机器上建立一个文件,用ls查看一下,以当前时间减去所显示的文件修改时间会得一个负值,这一问题对于网络文件服务器是一场灾难,文件的可靠性将不复存在。为避免产生本机错误,可从网络上获取时间,这个命令就是rdate,这样系统时钟便可与公共源同步了。但是一旦这一公共时间源出现差错就将产生多米诺效应,与其同步的所有机器的时间因此全都错误。
另外当涉及到网络上的安全设备时,同步问题就更为重要了。这些设备所生成的日志必须要反映出准确的时间。尤其是在处理繁忙数据的时候,如果时间不同步,几乎不可能将来自不同源的日志关联起来。 一旦日志文件不相关连,安全相关工具就会毫无用处。不同步的网络意味着企业不得不花费大量时间手动跟踪安全事件。现在让我们来看看如何才能同步网络,并使得安全日志能呈现出准确地时间。
Internet的发展使得电子货币,网上购物,网上证券、金融交易成为可能,顾客可以坐在家里用个人电脑进行上述活动。要保证这些活动的正常进行就要有统一的时间。不能设想用户3点钟汇出一笔钱银行2点50分收到。个人电脑的时钟准确度很低,只有10-4、10-5,一天下来有可能差十几秒。
现在许多在线教学系统的许多功能都使用了时间记录,比如上网时间记录,递交作业时间和考试时间等等。通常在线教学系统记录的用户数据均以网站服务器时间为准。笔者以前就曾出现过因为应用服务器时间还在23点55分,而数据库服务器已跨过24点,导致正在进行的整个批处理日切或数据归档等重要处理失败或根本无法进行的情况,其实应用和数据库服务器时间也只是相差了几分钟而已。为了避免出现这种情况,系统管理员要经常关注服务器的时间,发现时间差距较大时可以手工调整,但由系统管理员手工调整既不准确、并且随着服务器数量的增加也会出现遗忘,因此有必要让系统自动完成同步多个服务器的时间。
上述问题的解决方法,就是需要一个能调整时钟抖动率,建立一个即时缓和、调整时间变化,并用一群受托服务器提供准确、稳定时间的时间管理协议,这就是网络时间协议(NTP)。如果你的局域网可以访问互联网,那么不必安装一台专门的NTP服务器,只需安装NTP的客户端软件到互联网上的公共NTP服务器自动修正时间即可,但是这样时间能同步但不精准还可能因为网络不稳定从而导致时间同步失败的结果,最佳方案则是在网络里安装一台属于自己的NTP服务器硬件设备,将各个计算机时间同步且统一起来,成本也不高即便高相对于大数据服务器来说孰轻孰重,作为网络工程师你更清楚。
总结:
随着网络规模、网上应用不断扩大,网络设备与服务器数量不断增加。网络管理员在查看众多网络设备日志时,往往发现时间不一,即使手工设置时间,也会出现因时区或夏令时等因素造成时间误差;有些二层交换机重启后,时钟会还原到初始值,需要重新设置时间。对于核心网络设备和重要应用服务器而言,它们之间有时需要协同工作,因此时间的准确可靠性显得尤为重要。
NTP服务的配置及使用都非常简单,并且占用的网络资料非常小。NTP时间服务器目前广泛应用于网络安全、在线教学、数据库备份等领域。企业采取措施同步网络和设备的时间非常重要,但确保安全设备所产生的日志能提供精确的时间更应当得到关注。
只有一张表,数据量不大的情况。在B服务器的SQL
2008
数据库上创建A服务的服务器连接,然后定时删除b1表数据重新插入。
--创建链接服务器
exec
sp_addlinkedserver
'
SQL2000
',
'
',
'SQLOLEDB
',
'远程服务器名或ip地址
'
exec
sp_addlinkedsrvlogin
'SQL2000',
'false
',null,
'用户名
',
'密码
'
--配置计划任务定期执行
TRUNCATE
TABLE Bdbob1
INSERT
INTO
Bdbob1
SELECT
from
SQL2000Adboa1
如果a1表有自增列,或
时间戳
可以增量同步
--另外可以使用同义词,相当
于建
一个
超链接
,数据不会存储高B服务器,但数据与A服务器是时时的。
CREATE
SYNONYM
[dbo][b1]
FOR
SQL2000Adboa1
GO
--还可以利用SQL
Server
的复制功能,具体参考相关资料。1
sql
server
复制:事务发布
2
配置发布服务器,
3
快照发布:隔一段时间会覆盖订阅服务器的数据库,在订阅服务器上做的修改同样被覆盖;
4
事务发布:是一种接近实时地从源到目标分发数据的方法;
5
具有可更新订阅的事务发布:订阅服务器可更新发布服务器的数据;
6
合并发布:发布服务器和订阅服务器的更新都会同步到对方,注意id在合并发布上的冲突
7
1
在sql
server下实现发布服务器和订阅服务器的通信正常(即可以互访),打开1433端口,在防火墙中设置入站规则;
8
2
发布服务器与订阅服务器的sql
server
agent代理帐号必须设置的一样,否则不能互访;
9
3
如果你希望在复制的过程中一并复制非聚集索引,可以对发布属性-项目进行如下设置,修改完之后需要重新生成快照;
欢迎分享,转载请注明来源:内存溢出
评论列表(0条)