Ну я под теребайт перетаскивал. И 2 терабайта документов. Без особых проблем. Взяли стендбай базу, мышкой кликнули, подождали часов 10. База на SAN. Мышкой кликнули, перетащили на новый сервер. Мышкой клинкнули, подождали 10 часов, база на локальных дисках. Переключили стендбай и праймари, повторили. Все заняло две пятницы. Какие проблемы то?Easbayguy wrote:Класно когда базы такие маленькие что их можно кликнув мышкой перетащить. Или целый МФ с 5ТБ данных!
У вас всегда будет продакшен сервер, стейджинг, что -то еще. Между ними и делается стендбай. Да и если сервер выделенный Оракл вполне идет навстречу по льготному лицензированию.Easbayguy wrote:Oracle license, они тоже кусаются!Dmitry67 wrote:StrangeR, так представьте сколько IBM заломит за DR...
Dmitry67 wrote:Это да. Или ms sql, для полноценного mirroring нужно asynchronous, а это enterprise. Не говоря уже о availability groups...Easbayguy wrote:Oracle license, они тоже кусаются!Dmitry67 wrote:StrangeR, так представьте сколько IBM заломит за DR...
P.S.
Мы тут считали стоимость Enterprise MS SQL, так вот, стоимостью железа можно пренебречь
Да ни к какому заметному падению производительности синк редим не приводит. Мы меряли много раз. Все зеркала абсолютно синхронны и находятся рядом. Но это не ДР а именно локальный кластер базы данных. Передачса на DR естественно асинхронно должна идти. Но он на то и ДР, на случай ядреной бомбы или там падения самолета на дата центр.Dmitry67 wrote:Ну как я уже писал, sync редим привот к совершенно катастрофическому падению производительности
async же вы скорее потеряете секунду две максимум.
А в случае реального DR (ядрена бомба, нашествие зомби, эбола в DataCenter) секунду вам простят
А в случае Planned DR (снежный апокалипсис, нет электричества, генератор без топлива скоро остановится) все данные перельются корректно
P.S.
Тут я где то читал про то как куча фирм при DR получали несколько часовой split brain и ничего
ну вот в случае с ораклом не очень понятно нафига Async, если "Planned DR" то можно совершенно бесплатно просто раз в пару минут скидывать архивные логи на стебай, который будет их накатывать. в случае надобности я просто дам команду switch logs и переключу на Async ноду, которая после switch logs, получит архивный лог с последней транзакцией. умельцы такой "стендбай" для оракла даже продают http://www.dbvisit.comDmitry67 wrote:Ну как я уже писал, sync редим привот к совершенно катастрофическому падению производительности
async же вы скорее потеряете секунду две максимум.
А в случае реального DR (ядрена бомба, нашествие зомби, эбола в DataCenter) секунду вам простят
А в случае Planned DR (снежный апокалипсис, нет электричества, генератор без топлива скоро остановится) все данные перельются корректно
Или я Вас не понимаю или Вы меня.StrangerR wrote:А мешает похоже стоимость. Потому что все таки у того же Гугла огромная, надежная сторейдж состоит из дешевых массовых железок, которые могут ломаться как хотят и системе хоть бы хны.
Я не случайно про это пишу. Мне об этом тренде - переход на дешевые железки, уход с железных райдов и всякого спец железа, как пример - идет уход с супер-пупер FC на простую софтверную iSCSI, причем мы например даже при наличии железной поддержки юзаем чисто софтовую - надежнее и гибче - говорят на каждом семинаре по сторейджу.
С ума сойти. У меня первое требование к любой продакшен базе - всегда, без исключений, physical standby (не зеркало дисков и тем паче не РАК а именно Data Guard ну или MS SQL mirror. Причем это не дорого, у всех провайдеров базы если стендбай только стендбаит его можно не лицензировать отдельно, да и никто не мешает на нем стейджинг делать и взаимно миррорить. СУБД без зеркала вообще не способна выполнять требования по SLA на продакшен. Как вы ее простите апгрейдить будете, сам сервер или там OS? Или перетаскивать на новое железо /даже в VMWARE даже онлайн перетаскивание легко делается на средне нагруженном стендбае но плохо на первичной базе, есть шанс алармы поиметь).Это слишком дорого. В нашей отрасли - энергетика так не делают, (хотя за всю отрасль мне наверно не стоит зарекаться).
Ужас!Dmitry67 wrote:О, спасибо за конкретику
$1500/1Gb RAM
Только память одного нашего ESX стоила бы 288K
А всех десяти 2.88M
Это только PROD, и только в одном Datacenter, и только память
Там обычные байты, но это МФ и эта memory - redundant array of independent memory (RAIM).Dmitry67 wrote:Да, я думаю память такая дорогая потому что там особенные, неметрические байты
А что maximum protection mode уже отменили в data guard?iDesperado wrote:ну вот в случае с ораклом не очень понятно нафига Async, если "Planned DR" то можно совершенно бесплатно просто раз в пару минут скидывать архивные логи на стебай, который будет их накатывать. в случае надобности я просто дам команду switch logs и переключу на Async ноду, которая после switch logs, получит архивный лог с последней транзакцией. умельцы такой "стендбай" для оракла даже продают http://www.dbvisit.comDmitry67 wrote:Ну как я уже писал, sync редим привот к совершенно катастрофическому падению производительности
async же вы скорее потеряете секунду две максимум.
А в случае реального DR (ядрена бомба, нашествие зомби, эбола в DataCenter) секунду вам простят
А в случае Planned DR (снежный апокалипсис, нет электричества, генератор без топлива скоро остановится) все данные перельются корректно
дорого стоит гарантия каждой транзакции, но я честно не знаю используется ли у нас Sync, где-то, но мне кажется должны. иначе катастрофа, всего в паре байтов одной транзакции могли миллионы перемещаться, если транзакция потеряется, это пипец