Ну я под теребайт перетаскивал. И 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, где-то, но мне кажется должны. иначе катастрофа, всего в паре байтов одной транзакции могли миллионы перемещаться, если транзакция потеряется, это пипец
Можно включать RAIM, но мы никогда не делали, так как проще зеркалить то что критическое.zVlad wrote:Там обычные байты, но это МФ и эта memory - redundant array of independent memory (RAIM).Dmitry67 wrote:Да, я думаю память такая дорогая потому что там особенные, неметрические байты
А у Вас это во-первых не МФ мемори, а во-вторых... как там у Вас с RAIM?
Даа. У нас 4 терабайта пампяти в двух облаках. Это что, 6 миллионов нам заплатить надо было бы??zVlad wrote:Ужас!Dmitry67 wrote:О, спасибо за конкретику
$1500/1Gb RAM
Только память одного нашего ESX стоила бы 288K
А всех десяти 2.88M
Это только PROD, и только в одном Datacenter, и только память
ТО что вы пишете, тоже иногда делается. Но это совсем не эквивалентно зеркалу базы данных, это намного слабее. Ну например, как вы патчи на сервер базы данных будете накладывать?zVlad wrote:
Или я Вас не понимаю или Вы меня.
Я правильно понимаю что Вы говорите о двух систем instances с двумya базами которые между собой занимаются репликацией данных в реальном времени (online)? Один instance работает с юзерами второй только отслеживает изменение данных. Если первый сдох юзера перекидываются на второй.
У нас используется реальный дисковый mirror (похоже с легкой руки MS термин "mirror" стал использоваться и для "репликация"). Всех дисков на которых размещается Production. В случае дизастера, на DR сайте делается загрузка системы и стартуют БД и app. serevra. Чем этот подход лучше по нашему по МФ-скому? DR сайт - это второй МФ на котором выполняются другие Production, других приложений. Если на нем держать "горячий" standby, то для него нужны дополнительные MIPS. Посколько DR не так уж и часто происходит, а за доп MIPS платить придется всегда, то это по крайней мере некрасиво, а на самом деле было бы идиотизмом (я понимаю у Вас все дешевое, $10000 тута 10 сюда, это ж ведь не миллионы).
Фактически в ожидании DR для DR мы не тратим цента за МФ, мы платим только за диски и за их возможность самореплицироваться.
Так это и есть DG в режиме ARCH. Он так и работает. А я так примерно реализую DR в случае MS SQL (реплицирую бэкапы и имею скрипт для их автоматического накатывания)"Planned DR" то можно совершенно бесплатно просто раз в пару минут скидывать архивные логи на стебай, который будет их накатывать
А у нас 2терабайта на datacenter в Prod. Таких 4. Плюс dev, qa, vdi. Итого около 12тStrangerR wrote:Даа. У нас 4 терабайта пампяти в двух облаках. Это что, 6 миллионов нам заплатить надо было бы??zVlad wrote:Ужас!Dmitry67 wrote:О, спасибо за конкретику
$1500/1Gb RAM
Только память одного нашего ESX стоила бы 288K
А всех десяти 2.88M
Это только PROD, и только в одном Datacenter, и только память
Неа, мы тут супер мажорный апгрейд системы (переход на другие базовые библиотеки) загоняем в 12 часов, чтобы уложиться в 1 сутки. Больше - ни за что! В крайнем случае придется RO режим делать или SSD ставить для ускорения.Dmitry67 wrote:А у нас с downtime хорошо... в общем, весь викенд )
Не флейма ради, ещё раз спрошу - вы как-то замеряете необходимое количество памяти, или просто берёте самое большое что есть?Dmitry67 wrote:А у нас <до фигища>StrangerR wrote:Даа. У нас <до фига>
Есть инвентори, есть репорт сколько имеется сколько разместили сколько ОС (ВМваря) не дала. Обычная цифра напримерPalych wrote:Не флейма ради, ещё раз спрошу - вы как-то замеряете необходимое количество памяти, или просто берёте самое большое что есть?Dmitry67 wrote:А у нас <до фигища>StrangerR wrote:Даа. У нас <до фига>