Если вдуматься - что наша память? Кеш.Easbayguy wrote:В общем программисты/базы все хреновей и хреновей, необходимость держать все в памяти указывает на очень плохой дизайн приложения, фиговый движок и маленький обьем данных.
StrangerR wrote:ТО что вы пишете, тоже иногда делается. Но это совсем не эквивалентно зеркалу базы данных, это намного слабее. Ну например, как вы патчи на сервер базы данных будете накладывать?zVlad wrote:
Или я Вас не понимаю или Вы меня.
.....
....
StrangerR wrote:... Сам апгрейд занимает где то пару часов, так как там -патч, апгрейд, сервиспак, патч- надо наложить.
- сделали, все проверили. Переключили. Даунтайм 1 минута.
- так как 2005 не может миррорить 2008 то зеркало встало на паузу. Апгрейдим бывший праймари.
- заапгрейдили, запустили, зеркало синхронизовалось.
- переключили назад на основной праймари. Даунтайм еще 1 минута.
Как бы тут нам помогло реплицирование дисков? Зеркало в первую очередь нужно не для защиты от сбоя железа хотя и это не вредно (а если база напишеть чушь в файл?) а для бесперебойности сервиса. Аналогично с кластером NFS - он еще ни разу не был нужен для защиты от сбоя но постоянно используется для разных апдейтов и прочего... без прерывания сервиса.
...
Code: Select all
SITE1 SITE2
DB01 ---> ASYNC replciation --+
^ !
! !
SYNC replication +---> DRDB01
! !
DB02 ---> ASYNC replication --+Это хороший подходНет, Вы меня все таки не поняли. Зеркалируется все, и БД и система и вообще все, все. Все диски на которых работает instance.
но не без кучи граблей. Во первых, такое зеркало никогда не будет синхронным. во вторых, оно зазеркалирует все изменения в том числе например и 100 гигов временной таблицы. В третьих, оно же зазеркалирует ошибочно записанные данные из за которых база грохнулась. В четвертых, если 2 сайта, то там кое что разное бывает. Такое зеркалирование поддерживается той же VMware но вот только это именно DR а не бесперебойность сервиса.Вы не только в DR ничего не понимаете, но и с зеркалированием запутались напрочь.StrangerR wrote:DR защита у меня была. Зеркало не обеспечивает DR защиту а обеспечивает бесперебойность главного сервиса. ..... Такое зеркалирование поддерживается той же VMware но вот только это именно DR а не бесперебойность сервиса.
Для этих граблей делается backup и restore чтобы исправить ошибочные данные, DR для этого естественно не применим, DR нужен для того чтобы быть максимально близко к состоянию основного сайта (Р.S. Каким бы он не был) в момент когда основной сайт физически разрушен. Вдумайтесь в это и Вы все поймете. DR это не локальный failover.StrangerR wrote:....Это хороший подход
Вот так проваливаются разведчикиStrangerR wrote:...переписав роскошные drop from TABLE where УСЛОВИЕ...
зеркало зеркалу рознь. Синхронный стендбай базы данных - средство High Availiability а также средство zero downtime при мейнтенсах.zVlad wrote:Вы не только в DR ничего не понимаете, но и с зеркалированием запутались напрочь.StrangerR wrote:DR защита у меня была. Зеркало не обеспечивает DR защиту а обеспечивает бесперебойность главного сервиса. ..... Такое зеркалирование поддерживается той же VMware но вот только это именно DR а не бесперебойность сервиса.
Не знаю кто там проваливается, но почему то многие разработчики любят не думая написать что нибудь вроде, и включить в чейнджсетtengiz wrote:Вот так проваливаются разведчикиStrangerR wrote:...переписав роскошные drop from TABLE where УСЛОВИЕ...
Да нет, дело не в этом, это скорее "у Вас ус отклеился"StrangerR wrote:drop from BalanceEntries where value = 0...
. Нет такого синтаксиса в SQL. Должно быть "delete from....".
Зато он всем скрипты переписывает! И учит, "как надо"tengiz wrote:Нет такого синтаксиса в SQL. Должно быть "delete from....".StrangerR wrote:drop from BalanceEntries where value = 0...
Понятно что Вы имеете в виду, но как-то Вы уж слишком общо обобщаете и нарезать большую операцию на серию маленьких часто может быть нетривиально, так как несмотря на то, что полная операция может быть неатомарной, маленькие в серии в иных случаях обязаны быть атомарными, причем не на произвольных границах, а на вполне определенных. Студентов такому не учат. Это уже при работе на конкретном датабазном продукте нужно шишки набивать. И у разных датабазных продуктов разные удобные и эффективные способы с такими вещами бороться чтобы не было логов-бегемотов.StrangerR wrote:а потом уже на тестировании на реальных объемах мы удивленно видим лог файл размером с бегемота и время работы измеряемое чуть ли не сутками... И так не первый раз. Так транзакции на БОЛЬШОЙ (точнее даже средней) базе не пишутся. Эта операция не обязана быть атомарной (мы чистим ненужне записи) а значит - пишем её через итерации, небольшими транзакциями. Чтобы и лог файл не рос и можно было обломиться а потом продолжить. Я уж не знаю, где нынешних студентов учат, я все таки не DBA но даже пришлось завести скрипт универсальный и каждый раз показывать, как _это_ надо переписать...
Ну delete конечно... Описаться можно ? Я же написал, я базу программирую не очень часто, в основном когда серьезные база кодеры на грабли наступают. И синтаксис наизусть не помню... Когда нужно, открываю книжку или предыдущий скрипт и пишу.. какие проблемы то.. Может, ктото еще попросит наизусть оракловый rman запомнить? К терапевту...tengiz wrote:Да нет, дело не в этом, это скорее "у Вас ус отклеился"StrangerR wrote:drop from BalanceEntries where value = 0...
Я уже написал. Для того чтобы точно помнить синтаксис, есть книжки и примеры. Я и не помню. Но скрипты пишу постоянно, в том числе для обработки базы - совсем недавно пришлось переписыватЬ для MS SQL, и бэкапы оракла (строк 500 на rman) и прочее. А упомнить наизусть все тонкости синтаксиса shell / bash / perl / mysql / ms sql / oracla sqlplus / rman / еще в винде бывает bat как то пару тысяч строк пришлось на нем наваять / еще php попадался / и прочее... нафиг нафиг. Для синтаксиса есть reference manual. Ну и drop понятно что там delete, и что с того? Все работает, в том числе и переписанный скрипт и кластеры и зеркала и DR. И что интересно, без миллионных вложений в мейн фреймы. А с кластерами мы еще во времена Бэсмов работали.Зато он всем скрипты переписывает! И учит, "как надо"
Это то понятно.нарезать большую операцию на серию маленьких часто может быть нетривиально, так как несмотря на то, что полная операция может быть неатомарной, маленькие в серии в иных случаях обязаны быть атомарными, причем не на произвольных границах, а на вполне определенных.
Гмм. А чему их учат? Синтаксису команды delete from table или join в SQL-е? Или все таки может надо учить правильному кодированию а не тому какой там синтаксис? А то меня поражает число ляпов, которые приходят от девелоперов, особенно правда от китайских (например выборка кусочков данных методом пропуска N записей, выбора M, затем N += M, и по новой, при забытом напрочь ODER BY... блин, ловили эту чуду 2 месяца пока не поймали, автор при том так и остался неизвестным...)Студентов такому не учат.
Можно, конечно.StrangerR wrote:Ну delete конечно... Описаться можно ?
Опять, понятно, что Вы имеете в виду, но то что написано буквально - неправильно.StrangerR wrote:- таблица блокируется на время оной транзакции, по крайней мере на запись (на чтение зависит от isolation level в MS SQL)
- все что там было переписывается в логи в redo записи (ну или в оракле в redo tablespace)
Их учат моделированию данных, нормальным формам и прочей реляционной азбуке. И да, синтаксису SQL. "Кодировать" не учат нигде и ни на каком языке, насколько я могу судить. Практически ВСЕХ кто приходил, скажем, к нам без реального опыта работы (в индустрии "на поток") нужно было учить кодировать заново. Самый ужасный код обычно писали бывшие "академики", но не всегда. И я сам через такое тоже проходил. Уже после примерно года работы в MS SQL на свой собственный C++ код написанный до того было больно смотреть - код должен быть простым, понятным и однообразным, написанным разборчивым почерком, так сказать. Умничать при написании продакшен когда никогда нельзя, за исключением когда это очень нужно, но нужно это бывает очень редко.Гмм. А чему их учат? Синтаксису команды delete from table или join в SQL-е? Или все таки может надо учить правильному кодированию а не тому какой там синтаксис?
забавный случай, но ДБА там явно не причем. виноват менеджер, не внедривший хотя бы базовые вещи по контролю. не было approve от QM, патч не протестировали на TEST и PREPROD, approve от продукт овнера не было. там ошибка была не в запросе, а в производственном процессе.Dmitry67 wrote:Drop вместо delete. А один DBA к delete забыл добавить WHERE. И выполнил команду (до этого он пару суток не спал). И удалил все записи за минуту, как в эфир пошла реклама этой фирмы и все ломанулись на этот сайт. И его расстреляли.
Ну вот мы уже про HA вспомнили. Скоро, говоря, о всего лишь DR вспомним все технологии IT не важные с точки зренуя юзера.StrangerR wrote:зеркало зеркалу рознь. Синхронный стендбай базы данных - средство High Availiability а также средство zero downtime при мейнтенсах.zVlad wrote:Вы не только в DR ничего не понимаете, но и с зеркалированием запутались напрочь.StrangerR wrote:DR защита у меня была. Зеркало не обеспечивает DR защиту а обеспечивает бесперебойность главного сервиса. ..... Такое зеркалирование поддерживается той же VMware но вот только это именно DR а не бесперебойность сервиса.
Потаря сайта амбивалентна к любым платформам, поэтому выделять специально МФ здесь не обязательно.StrangerR wrote: Асинхронное, скорее всего снапшотное, зеркало сторейджа - средство защиты от потери сайта или вашей супер МейнФреймы. Оно всегда будет отставать, будет копировать кучу ненужного. Обычно делают комбинированное решение
- приложения, сами ОС и прочее защищают так как у вас, реплицированием на уровне SAN системы. Потому как они меняются редко и мало.
- данные (базу и файлы, особенно базу) реплицируют на уровне логическом, например базу - синхронным стендбаем. Ну или если репликация в другой город то асинхронным.
StrangerR wrote: А так... сторейдж она реплицирует снапшоты, или же все транзакции вынуждены идти по каналу связи то есть он должен быть таким же как ширина вашего IO. В итоге (1) реплика отстает потому что снапшотная, и (2) реплицируется куча никому не нужного хлама, заодно. Нет, это хорошая стратегия, полная репликация на уровне SAN, но (1) очень дорогая по ресурсам, (2) вечно будет отставать то есть применима именно как DR _все пропало дата центр утонул_, и (3) если она не на VM то её нелегко тестировать. Обычно это применяют именно как DR между удаленными сайтами. Мы рассматривали такую возможность, но пока плюнули, обошлись rsync + DB репликацией + как я сказал - локально синхронное зеркало базы, удаленно репликация асинхронная другими средствами. Репликация дисков серверов базы данных - ну вероятно прошла бы ели снапшот раз в 20 минут делать, но канал бы потребовался раз в 10 толще чем сейчас.
(Я про один только проект. Их много, в других может и дисковая репликация встретиться. Но я пока как то ей не вдохновился.)
еще одно подтверждение, что в МФ столько же мощи, сколько в моем ноутбуке. в мире PC люди уже на скромных системах испытывают трудности реплицировать только транзакшен лог базы банных, в то время как МФ на тех же каналах связи успевает реплицировать не только лог базы данных, но и целиком все изменения дисков. т.е. и/о система МФ просто не в состоянии забить современные каналы связи, потому можно запросто реплицировать в соседний город. удобно.zVlad wrote: 3. Завершение. Потерянная в "етом городе" система загружается в DR LPAR с реплицированных дисков. Юзеры начинают в ней работать
Как то у Вас легко получается свалить в одну кучу разные вещи и найти в ней какую то общность. В данном случае собственно программирование и архитектуру ИТ замесили вместе. ИВМ МФ это действительно не бутерброд какие Вы видимо складываете из дешевых ингредиентов, которые чудом умудряются работать все вместе и давать результат. С точки же зрения программирования нет никакой разницы какая БД выполняет запросы и где она стоит и нет разницы где стоит WebSphere чтобы ранить Java (кстати Java может раниться и под "древним" CICS и не только Java но и Web Services тоже). Так что с точки зрения программирования МФ ничем не уступает Вашим бутербродам и даже превосходит их потому что не будерброд, из которого вечно наровит что нибудь выпасть когда его ешь.StrangerR wrote:Да нет, ну я преувеличиваю конечно. Я понимаю zVlad-а, который видит тот ужас что пишут в области _массового программирования_ и то что получается когда вместе лепим многоуровневый бутерброд (NetApp / VMWare / 100 хостов / 1000 VM под 10 операционками... а еще разные SAN и прочее вокруг, не считая нетаппов...) и сравнивает с чистой красивой архитектурой МФ. Я и сам вспоминаю код Алгола ГДР и кажется еще и Фортран ГДР был - чисто, красиво, по немецки аккуратно, без единой лишней запяток... а потом открываем что нибудь на жабе или C++ и ужасаемся...
Тем не менее, к сожалению, и МФ и _чистый красивый очень компактный код_ уходят в прошлоее. А на их место - сотня ПС серверов, тысяча индусских кодеров, и парочка грамотных архитекторов... Кстати, напоминает как ЕС вытеснила (точнее ИБМ) Бэсм - конечно бэсм была чистой красивой аккуратной, ЕС сборищем убожества, но ... функциональность важнее красоты...
А для этого есть полиси. Вы вот не поверите но у нас ДБА _не имеет права_ работать с продакшен базой. НЕ ИМЕЕТ. И никогда не работает.Dmitry67 wrote:Drop вместо delete. А один DBA к delete забыл добавить WHERE. И выполнил команду (до этого он пару суток не спал). И удалил все записи за минуту, как в эфир пошла реклама этой фирмы и все ломанулись на этот сайт. И его расстреляли. Место освободилось, и меня взяли в этот стартап. Это.было более 10 лет назад в Америке... так что для production dba опечатка в одну букву может быть концом карьеры )
Ну, если у вас это тестирование то мы так тестируеем ДР раз в две недели, потому что он используется для тестирования. Но это именно ТЕСТОВЫЙ режим. Не реальный. Потому что реально так ничего не оттестировать. Продакшен система посылает в Банк Оф Америка еженочно данные о списании денег. Как протестировать ДР на то что он будет это делать? Продакшен система проверяет рейт на реальном сайте, тестовая на тестовом, как проверить то что ДР сможет работать с реальным сайтом? Это тестовый режим ДР который тестирует его лишь наполовину. Знакомо, проходили уже, используем лет 5. Только вот на реальных ресурсах под ДР даже СПУ освобождать не приходится потому что на интел облаке ресурсов хватает и без того.3. Завершение. Потерянная в "етом городе" система загружается в DR LPAR с реплицированных дисков. Юзеры начинают в ней работать. Для Test DR используется свой IP address конечно, потому нормальная работа ведь продолжается. В случае настоящего DR IP конечно не меняется.
Да не успевают они ничего реплицировать. Это просто физически невозможно. Они реплицируют снапшоты, с дедупликацией, раз в один - два часа в лучшем случае. Никакой синхронной репликации или пусть даже асинхронной но полной там не происходит. Так как никаких каналов на оную не хватило бы.iDesperado wrote:еще одно подтверждение, что в МФ столько же мощи, сколько в моем ноутбуке. в мире PC люди уже на скромных системах испытывают трудности реплицировать только транзакшен лог базы банных, в то время как МФ на тех же каналах связи успевает реплицировать не только лог базы данных, но и целиком все изменения дисков. т.е. и/о система МФ просто не в состоянии забить современные каналы связи, потому можно запросто реплицировать в соседний город. удобно.zVlad wrote: 3. Завершение. Потерянная в "етом городе" система загружается в DR LPAR с реплицированных дисков. Юзеры начинают в ней работать