Репликация - История изменений

SYSDBA в 17:17, 22 августа 2009

2009-08-22T17:17:07Z

SYSDBA в 17:16, 22 августа 2009

2009-08-22T17:16:47Z

SYSDBA в 14:22, 22 августа 2009

2009-08-22T14:22:18Z

SYSDBA: /* По времени проведения сеанса репликации */

2009-08-22T14:08:41Z

‎По времени проведения сеанса репликации

SYSDBA в 14:07, 22 августа 2009

2009-08-22T14:07:10Z

SYSDBA в 10:42, 21 августа 2009

2009-08-21T10:42:32Z

SYSDBA в 20:29, 13 января 2007

2007-01-13T20:29:41Z

Новая страница

Процесс переноса изменений, сделанных на одной базе данных, на другие базы.

@@ Строка 1: / Строка 1: @@
 Процесс переноса изменений, сделанных на одной базе данных, на другие базы.
 Классификация репликации на основе [http://replication.chat.ru/ статьи]:
@@ Строка 22: / Строка 20: @@
 [[Category:Репликация]]

← Предыдущая		Версия 17:16, 22 августа 2009
Строка 1:		Строка 1:
	Процесс переноса изменений, сделанных на одной базе данных, на другие базы.		Процесс переноса изменений, сделанных на одной базе данных, на другие базы.
		+
		+	__NOTOC__

	Классификация репликации на основе [http://replication.chat.ru/ статьи]:		Классификация репликации на основе [http://replication.chat.ru/ статьи]:

@@ Строка 13: / Строка 13: @@
 === По способу передачи информации во время процесса репликации ===
-Если соединение серверов, хранящих распределенные БД, происходит при помощи программы клиента, которая с одной стороны коннектится к своему серверу, а с другого конца имеет прямую связь с БД другого сервера и может подключиться напрямую к данным другого сервера, для прямого изменения и анализа реплицируемых данных с обеих концов, имея при этом гарантированный устойчивый канал связи (ADSL, выделенный канал, двупроводная линия Dial-Up и пр.), то такой вид синхронизации назовем прямым. Если же канал неустойчивый и не гарантирует устойчивую связь без падений во время процесса синхронизации и данные приходится передавать цельными пачками, при этом принимающая сторона во время закачки и анализа данных не имеет немедленной возможности опросить источник при возникновении на ее взгляд сомнительных моментов, а решение "Что делать?" принимать в любом случае нужно, то такой вид синхронизации будем называть недетерминированной или вероятностной.
+Если соединение серверов, хранящих распределенные БД, происходит при помощи программы клиента, которая с одной стороны коннектится к своему серверу, а с другого конца имеет прямую связь с БД другого сервера и может подключиться напрямую к данным другого сервера, для прямого изменения и анализа реплицируемых данных с обеих концов, имея при этом гарантированный устойчивый канал связи (ADSL, выделенный канал, двупроводная линия Dial-Up и пр.), то такой вид синхронизации назовем '''прямым'''. Если же канал неустойчивый и не гарантирует устойчивую связь без падений во время процесса синхронизации и данные приходится передавать цельными пачками, при этом принимающая сторона во время закачки и анализа данных не имеет немедленной возможности опросить источник при возникновении на ее взгляд сомнительных моментов, а решение "Что делать?" принимать в любом случае нужно, то такой вид синхронизации будем называть '''недетерминированной''' или '''вероятностной'''.
 === По способу анализа реплицируемой информации ===
-Если ядро алгоритма работает по принципу сравнения записей одной таблицы с записями другой, и на основании этого принимается решение о синхронизации, то такой процесс будем называть репликацией по текущему состоянию. Если в базе предусмотрен журнал вносимых изменений в БД, и алгоритм репликации переносит измененя по дельтам изменений накопленным в журнале, то такой процесс назовем дельта репликацией.
+Если ядро алгоритма работает по принципу сравнения записей одной таблицы с записями другой, и на основании этого принимается решение о синхронизации, то такой процесс будем называть '''репликацией по текущему состоянию'''. Если в базе предусмотрен журнал вносимых изменений в БД, и алгоритм репликации переносит измененя по дельтам изменений накопленным в журнале, то такой процесс назовем '''дельта репликацией'''.
 [[Category:Репликация]]

@@ Строка 10: / Строка 10: @@
 Если данные должны быть засинхронизированны немедленно после изменений, то такую репликацию будем называть репликация реального времени. Если же процесс репликации запускается по какому либо событию во времени или по отмашке администратора БД, то такой вид репликации назовем отложенная репликация.
-  III. По способу передачи информации во время процесса репликации. Если соединение серверов, хранящих распределенные БД, происходит при помощи программы клиента, которая с одной стороны коннектится к своему серверу, а с другого конца имеет прямую связь с БД другого сервера и может подключиться напрямую к данным другого сервера, для прямого изменения и анализа реплицируемых данных с обеих концов, имея при этом гарантированный устойчивый канал связи (ADSL, выделенный канал, двупроводная линия Dial-Up и пр.), то такой вид синхронизации назовем прямым. Если же канал неустойчивый и не гарантирует устойчивую связь без падений во время процесса синхронизации и данные приходится передавать цельными пачками, при этом принимающая сторона во время закачки и анализа данных не имеет немедленной возможности опросить источник при возникновении на ее взгляд сомнительных моментов, а решение "Что делать?" принимать в любом случае нужно, то такой вид синхронизации будем называть недетерминированной или вероятностной.
-  IV. По способу анализа реплицируемой информации. Если ядро алгоритма работает по принципу сравнения записей одной таблицы с записями другой, и на основании этого принимается решение о синхронизации, то такой процесс будем называть репликацией по текущему состоянию. Если в базе предусмотрен журнал вносимых изменений в БД, и алгоритм репликации переносит измененя по дельтам изменений накопленным в журнале, то такой процесс назовем дельта репликацией.
+=== По способу передачи информации во время процесса репликации ===
 [[Category:Репликация]]

← Предыдущая		Версия 14:07, 22 августа 2009
Строка 1:		Строка 1:
	Процесс переноса изменений, сделанных на одной базе данных, на другие базы.		Процесс переноса изменений, сделанных на одной базе данных, на другие базы.
		+
		+	Классификация репликации на основе [http://replication.chat.ru/ статьи]:
		+
		+	=== По направлению репликации ===
		+
		+	Если данные изменяются только в одной из БД, а в другой данные только хранятся и не подвергаются изменениям, то такую репликацию будем называть '''однонаправленной''' или '''односторонней'''. Если же данные могут изменяться и вводиться на всех БД, то такой вид репликации будем называть '''мультинаправленной''' или '''многосторонней'''.
		+
		+	=== По времени проведения сеанса репликации ===
		+
		+	Если данные должны быть засинхронизированны немедленно после изменений, то такую репликацию будем называть репликация реального времени. Если же процесс репликации запускается по какому либо событию во времени или по отмашке администратора БД, то такой вид репликации назовем отложенная репликация.
		+	III. По способу передачи информации во время процесса репликации. Если соединение серверов, хранящих распределенные БД, происходит при помощи программы клиента, которая с одной стороны коннектится к своему серверу, а с другого конца имеет прямую связь с БД другого сервера и может подключиться напрямую к данным другого сервера, для прямого изменения и анализа реплицируемых данных с обеих концов, имея при этом гарантированный устойчивый канал связи (ADSL, выделенный канал, двупроводная линия Dial-Up и пр.), то такой вид синхронизации назовем прямым. Если же канал неустойчивый и не гарантирует устойчивую связь без падений во время процесса синхронизации и данные приходится передавать цельными пачками, при этом принимающая сторона во время закачки и анализа данных не имеет немедленной возможности опросить источник при возникновении на ее взгляд сомнительных моментов, а решение "Что делать?" принимать в любом случае нужно, то такой вид синхронизации будем называть недетерминированной или вероятностной.
		+	IV. По способу анализа реплицируемой информации. Если ядро алгоритма работает по принципу сравнения записей одной таблицы с записями другой, и на основании этого принимается решение о синхронизации, то такой процесс будем называть репликацией по текущему состоянию. Если в базе предусмотрен журнал вносимых изменений в БД, и алгоритм репликации переносит измененя по дельтам изменений накопленным в журнале, то такой процесс назовем дельта репликацией.

	[[Category:Репликация]]		[[Category:Репликация]]

← Предыдущая		Версия 10:42, 21 августа 2009
Строка 1:		Строка 1:
	Процесс переноса изменений, сделанных на одной базе данных, на другие базы.		Процесс переноса изменений, сделанных на одной базе данных, на другие базы.
		+
		+	[[Category:Репликация]]