Копирование 100 ГБ с продолжением изменения файла между центрами обработки данных с R-синхронизацией - это хорошая идея? - PullRequest
0 голосов
/ 08 мая 2019

У меня есть центр данных A, в котором 100 ГБ файла меняется каждую миллисекунду. Мне нужно скопировать и поместить файл в центр обработки данных B. В случае сбоя в центре обработки данных A мне нужно использовать файл в B. Поскольку файл меняется каждую миллисекунду, может ли r-sync справиться с ним на расстоянии 250 миль от центра обработки данных? Есть ли возможность получить поврежденный файл? Как это постоянно обновляется, когда мы называем это как готовый файл в центре обработки данных B?

Ответы [ 2 ]

1 голос
/ 08 мая 2019

rsync - относительно простой инструмент для копирования файлов с некоторыми очень продвинутыми функциями.Это отлично подойдет для файлов и структур каталогов, где изменения происходят не так часто.

Если один файл с 100 ГБ данных изменяется каждую миллисекунду, это будет потенциальная скорость изменения данных 100 ТБ в секунду.На самом деле, я ожидаю, что скорость изменения будет намного меньше.

Хотя существует возможность возобновить передачу данных и потенциально частично использовать существующие данные, rsync не предназначен для непрерывной репликации в этот интервал.rsync работает на уровне файлов и не так часто используется как инструмент репликации на уровне блоков.Однако есть опция --inplace.Это может обеспечить вам тот тип синхронизации файлов, который вы ищете.https://superuser.com/questions/576035/does-rsync-inplace-write-to-the-entire-file-or-just-to-the-parts-that-need-to

Когда дело доходит до расстояния, 250 миль могут привести к дополнительной задержке, по крайней мере, 2 мс, если учитывать скорость света, что не так уж много.В действительности это было бы больше из-за кабелей, маршрутизаторов и коммутаторов.

rsync сам по себе, вероятно, не является правильным решением.Этот вопрос, кажется, больше касается физики, скорости соединения и бизнес-требований, чем что-либо еще.Было бы хорошо узнать точную частоту изменений и узнать, разрешено ли иметь пробелы в точках восстановления.Этот уровень надежности может потребовать более сложного решения, такого как доставка журналов, моментальные снимки хранилища, репликация хранилища или некоторая форма распределенного хранилища на внутренней стороне.

0 голосов
/ 08 мая 2019

Нет, rsync, вероятно, не является правильным способом синхронизации данных на основе вашего описания.

100 ГБ данных никому не нужны без средств для их обслуживания и извлечения информации. Это подразумевает структурированные элементы, такие как записи и индексы. Rsync ничего не знает об этой структуре, поэтому не может гарантировать, что запись в файл перейдет из одного допустимого состояния в другое. Это, безусловно, не может гарантировать какой-либо согласованности, если файл будет одновременно обновляться с обеих сторон и копироваться с помощью rsync

Rsync может быть правильным решением, но невозможно сказать из того, что вы сказали здесь.

Если вы говорите о подготовке репликации базы данных в режиме реального времени для целей восстановления после сбоя, то лучший способ - использовать репликацию транзакций на уровне СУБД. В противном случае рассмотрите что-то вроде drbd для репликации блоков, но имейте в виду, что вам придется применить восстановление после сбоя базы данных к реплицированной копии, прежде чем его можно будет использовать на удаленном конце.

...