кто тут себя считает самым крутым С программистом системным, объясните мне.

А как ты этим управлять собрался? Руками? Скриптами? Молодец.

Всё равно не могу понять, как RAC поможет мне реплицировать две разные БД между собой. RAC это же HA-кластер

ну вот конкретно эти ребята руками(скриптами) и управляют ораклом, об этом мне этот программист говорил, потому нужно хорошее умение писать скрипты.

ну вот конкретно эти ребята руками(скриптами) и управляют ораклом, об этом мне этот программист говорил, потому нужно хорошее умение писать скрипты.

Кстати, а SQL ты хорошо знаешь?

Известно что Celeron 1300 МГц работает гораздо быстрее многих Pentium 3 примерно такой же частоты.

Ты тут Celeron с Tualatin не перепутал? А Pentium 3 с Pentium 4(NetBurst)?

Аааа! Я скучал!

Такое ощущение, что последний оракл, который ты использовал - 9

http://docs.oracle.com/database/121/DBLIC/editions.htm

Изучай. Хинт для интереса ACFS. Хинт для интереса Data Guard. И да, я не слежу за всеми измениями Оракла.

Они не в Питере живут и на работу не жалуются.

Ну, почти все как я и говорил: кто тут себя считает самым крутым С программистом системным, объясните мне. (комментарий)

Как я, сисадмин, понимая разницу в обработке машинных кодов могу что-то оптимизировать?

Не бери в голову :) Моего кореша на швейную фабрику тоже сисадмин про кэши конкретных процессоров спрашивал — это не для приема на работу :) Это для отлупа кандидатов.

Ну и... нахрена это на швейной фабрике с парком 20 компов в бухгалтерии :)

Всё равно не могу понять, как RAC поможет мне реплицировать две разные БД между собой. RAC это же HA-кластер

Это не моя проблема, что ты не понимаешь абстракции. Если делать через Data Guard это будет твоя «классическая» репликация или ее вариация (хз с какими бд ты работаешь). Если делать через OCFS, то репликация на уровне файловой системы. Да, БД будет «якобы» одна. Но если раскидать по нескольким серверам, то окажется, что в случае выхода из строя одного сервака, то ничего не накроется. По твоим абстракциям это аналогично решению через heartbeat, где скриптиком перенастраиваются настройки приложения (веб-приложения, клиента и т.п.). А на деле это все эти решения относятся к репликации. Разрыв шаблона? Да, можно реплику делать через файлы (журнал/логи), через клиент-сервер на сокетах, да можно на уровне ФС.

Да, БД будет «якобы» одна. Но если раскидать по нескольким серверам, то окажется, что в случае выхода из строя одного сервака, то ничего не накроется. По твоим абстракциям это аналогично решению через heartbeat, где скриптиком перенастраиваются настройки приложения (веб-приложения, клиента и т.п.). А на деле это все эти решения относятся к репликации. Разрыв шаблона?

А в случае выхода хранилища, на котором сидит кластерная ФС? А в случае если я хочу среплицированную базу использовать для других целей (разработка, тест)?

Не нужно путать отказоустойчивость RAC (когда физически это одна БД с несколькими инстанциями) с несколькими экземплярами.

Я имел дело с этими процессорами уже Какой некро-процессор лучше? Celeron 1300 или Pentium 3 933 ?

А в случае выхода хранилища, на котором сидит кластерная ФС?

Странный вопрос. Отвечу. Кластерная ФС нигде не «сидит». Если накроются все сервера, то и хранилище накроется. До тех пор пока живо хотя бы один из серверов кластера, данные будут доступны. Для экстренных случаев используются бэкапы (ну, очевидно).

А в случае если я хочу среплицированную базу использовать для других целей (разработка, тест)?

Пожалуйста. Один из вариантов: делается холодный бэкап текущей БД, файлы БД переносятся на целевой сервер. На нем поднимается инстанс, основная БД и целевая настраиваются через Data Guard на работу по принципу Master-Slave. Оставшиеся данные из основной БД донакатываются на целевой сервер. В нужный момент целевой сервер выводят из режима реплики и переводят в боевой режим. Тестовый стенд с данными на текущий момент готов к работе и тестам.

Не нужно путать отказоустойчивость RAC (когда физически это одна БД с несколькими инстанциями) с несколькими экземплярами.

И никто не путает. Вопрос в том, что ты хочешь получить. А продукты оракла помогут тебе эту задачу решить. За деньги. Либо ты пилишь велик.

Пример RAC был приведен для случая master-master. Делать master-master через Data Guard или какой-то другой способ это извращения мастер-класса.

А может речь шла о статической/динамической типизации?

Изучай. Хинт для интереса ACFS. Хинт для интереса Data Guard. И да, я не слежу за всеми измениями Оракла.

Это ты о чём? О том, чего нет в SE (Data Guard)? Я это и так знал.

Кстати, ты не ответил на вопрос о том, почему RAC на SE это плохо.

Кстати, ты не ответил на вопрос о том, почему RAC на SE это плохо.

Все я тебе ответил. По линку что дал. Таблица «Table 1-1 Feature Availability for Oracle Database Editions», Scability: Quality of Service Management. Что это и зачем я пояснять не буду. Ищи сам. *Спокойно, спокойно*, читай пожалуйста документацию.

Странный вопрос. Отвечу. Кластерная ФС нигде не «сидит». Если накроются все сервера, то и хранилище накроется. До тех пор пока живо хотя бы один из серверов кластера, данные будут доступны. Для экстренных случаев используются бэкапы (ну, очевидно).

Я так, понимаю, ни OCF2, ни ACFS не являются рапределёнными ФС, соответственно работают поверх какого-то одного хранилища. Да, я знаю, что ASM можно использовать для избыточного хранения, но это не распределённое хранение.

Я так, понимаю, ни OCF2, ни ACFS не являются рапределёнными ФС

Давай так. Я тебе дам этот линк: http://docs.oracle.com/en/database/database.html и ты спокойно изучаешь все вопросы, которые тебя волнуют. Если возникнет вопрос, то ты не бежишь на ЛОР спрашивать, а продолжаешь читать доки, пока все не прочитаешь. Как прочитаешь все, ты приходишь на ЛОР и задаешь умные вопросы. Договорились? :)

P.S. Линк исправил.

Давай так. Я тебе дам этот линк: http://docs.oracle.com/cd/E11882_01/index.htm и ты спокойно изучаешь все вопросы, которые тебя волнуют. Если возникнет вопрос, то ты не бежишь на ЛОР спрашивать, а продолжаешь читать доки, пока все не прочитаешь. Как прочитаешь все, ты приходишь на ЛОР и задаешь умные вопросы. Договорились? :)

Т.е. я не прав про OCFS2 и ACFS, или кроме ссылки на документацию тебе нечего ответить?

Т.е. я не прав про OCFS2 и ACFS, или кроме ссылки на документацию тебе нечего ответить?

Все это гуглится за пять секунд. Лови: https://oss.oracle.com/projects/ocfs2/

Просто не ясно, тебе это интересно или ты просто хочешь поспорить ни о чем. Последнее мне не интересно, поэтому я пытаюсь направить тебя в нужное направление: интересоваться вопросом и получать ответы самостоятельно.

Все я тебе ответил. По линку что дал. Таблица «Table 1-1 Feature Availability for Oracle Database Editions», Scability: Quality of Service Management. Что это и зачем я пояснять не буду. Ищи сам. *Спокойно, спокойно*, читай пожалуйста документацию.

Напоминаешь того, кто интервьюировал ТСа - видишь только то, что знаешь.

Напоминаешь того, кто интервьюировал ТСа - видишь только то, что знаешь.

Да, ты прав. Я говорю про то, что знаю. Говорить о том чего не знаешь удел балаболщиков. Однако, я не стал тебе объяснять чем плох RAC в SE просто потому, что сам по себе SE убог. Тот же Data Guard. Я не стану говорить про QoS потому что можно обойтись без него, но имея его можно делать другие штуки. Вобщем, будь все так просто, то я бы сказал чем плох SE или EE.

В этой стране такие вопросы вообще не должны никого волновать. Ибо, сам знаешь про санкции. Бери у оракла все и не отдавай ничего!

Предлагаю дискуссию закончить. Я не против твоих знаний в Oracle и возможно, даже мне стоит чему-то у тебя поучиться.

Кстати, расскажи, что он говорил про KVM vs VMWare?

балахон, трубы, кроссовки. К чему неприязнь?

идут значит два рэпера...

На собеседования ходить стоит в приличном виде.

Есть такое модное слово devops, когда ни рыба ни мясо, но типа может и там и там. Этакий IT-бисексуализм :D

к рубашкам и брюкам придираются ещё больше, тут они хотя бы их цены не знают, а когда идёшь в классике это вообще ад. У моей юбка+блузка+колготки+шёлковое бельё под это и жакет стоят 21000. Потому что всё что дешевле, сразу начинаются придирки. Знакомая дизайнер с тендеров ушла, искала работу, я тогда сидел в чате hr. Так её внешний вид почти 2 часа разбирали, юбка типа дешёвая, блузка говно, как она в таком перед босом ходить типа будет... к директорам ещё понимаю одеться, а на собеседование с членосоской без разницы.

Ты про flashback database, насколько я понимаю.

Нет, FB всего лишь пользовательский интерфейс над всеми этими потрохами.

Странный вопрос. Отвечу. Кластерная ФС нигде не «сидит». Если накроются все сервера, то и хранилище накроется. До тех пор пока живо хотя бы один из серверов кластера, данные будут доступны. Для экстренных случаев используются бэкапы (ну, очевидно).

Ты же вещаешь глупости. OCFS(2)/ASM имеют вполне конкретное разделяемое хранилище, сервера в данном случае выступают только как front-end'ы к нему. Некорректный вывод из кластера любого из фронтов может убить сразу всю ФС или сделать её недоступной сразу везде на некоторе время.

Если делать через OCFS, то репликация на уровне файловой системы. Да, БД будет «якобы» одна. Но если раскидать по нескольким серверам, то окажется, что в случае выхода из строя одного сервака, то ничего не накроется.

И потому так вменяемые инженеры никогда не делают. Если решено выбрать репликацию, то используют копирование redo логов без общей ФС или потоковую репликацию на машины с независимыми ФС.

а можно мне тупому попроще и с примерами. Почему не стоит копировать весь носитель? Вот предположим, стойка, сервер и 3 дас хранилища. Читается с 1 даса, на остальные пишется, пишется средствами самих дасов, софт у делл видел, он умеет с другого даса копировать инфу. Можно ли назвать это репликой?Если сделать автоматическое переключение на следующий дас в очереди на чтение?

И потому так вменяемые инженеры никогда не делают.

Точно. Оракл делает поделия для лохов. Нормально комментировать не стану. Есть плюсы и минусы у каждого подхода. Каждый сам подбирает под себя шило и мыло.

Просто когда используется кластерные технологии то и говножелеза с софтверными рейдами, которые мрут как мухи вменяемые инженеры не используют. By design, то что ты описал относится только к говножелезу. А если нет денег на нормальное железо, то нефиг пытаться использовать RAC, OCFS и т.п. Оставайтесь, как говорится, в жопе. Никого это не волнует.

Повторю еще раз. Все извраты не использовать что-то серьезное из продукции оракла исходит в 99% случаев от того, что у кампании нету денег. Поэтому используют все что угодно. То, что можно получить за вменяемые деньги. Но никак не технологии от Оракла за лямы. Ибо, этих лямом нету.

ну вот например, есть 2 сервера обслуживающих приложения, у них есть дасы, в которых идёт копирование данных с мастера, в случае выхода из строя сервера, задачи переходят на второй, где есть своя копия данных. Чем это не вариант репликации?

Чем это не вариант репликации?

А где я говорил, что это не вариант? Товарищ mashina говорит будто кластерные фс не используются в репликах, а используются олдскульные методы через гоняние файлов по сети. Не вопрос. Шило. И. Мыло.

Минус работы с «переключалками» в переключателях. Которые могут «тупить» в тех случаях, где тупить нельзя by design.

Судя по сбербанку и их вечному «терминал не может подключится к базе»(образно), большинству глубоко похрен. А если уж даже сберу похрен...

да ничего не говорил, он спросил у меня что я предпочитаю и почему, согласился со мной, что vmware сейчас перевод денег.

а можно мне тупому попроще и с примерами. Почему не стоит копировать весь носитель? Вот предположим, стойка, сервер и 3 дас хранилища. Читается с 1 даса, на остальные пишется, пишется средствами самих дасов, софт у делл видел, он умеет с другого даса копировать инфу.

Примерно по такой же причиние почему и RAID1 не заменяет бэкапов. Испортишь как-нибудь оригинальную ФС и все негативные изменения разъедутся на все клоны - т.е. клоны как бы есть, но все одинаково нерабочие.

Можно закостылить снапшотами блочных устройств если DAS/SAN это умеют, но это уже будет значительно дороже по дискам (нужно держать много снапшотов т.к. не знаешь когда произошла порча ФС), будет какая-то значительная гранулярность по времени и вообще DAS навряд ли осилит много снапшотов.

Можно ли назвать это репликой?

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

Если сделать автоматическое переключение на следующий дас в очереди на чтение?

Это не так то просто сделать практически. Чтобы это всё заработало нужно

• остановить старый инстанс СУБД и отключить его физически от DAS,
• поднять ФС на другой машине и убедиться что ФС смогла всё пережить нормально - т.е. её журнал накатился, никаких ошибок при монтировании не обнаружилось и вообще хорошо было бы прогнать fsck.
• поднять саму СУБД и убедиться что она смогла прочитать свои redo логи и успешно их накатить на файлы данных.

На любой из этих стадий могут возникнуть нештатные ситуации требующие нетривиальных действий админа. Такой failover почти всегда ручное действите.

Мне интересен ваш опыт. Часто у вас бывают порчи дисков в рейдах? Вот именно как вы описываете, из-за ФС, а не физического износа или брака. Может дело в вашей ауре или отсутствии таковой у других людей. Серьезно.

И вы слышали про ZFS? Хотя, диски-то нынче дорогие, да. Для вас это не вариант. Даже с учетом того, что при проектировании ZFS учитывалось, что использоваться будет на дешевых дисках. Да и снапшот-то сам может запороться еще, и чексам запоротся.

Извините.

Точно. Оракл делает поделия для лохов.

Если есть одно изделие сделанное ораклом и какой-то другой его продукт, то из этого не следует что их можно и нужно дружить вместе. Тем более оракл рекомендует другие схемы и свой OCFS2 в подобных сценариях не продвигает.

Нормально комментировать не стану.

Конечно, не станешь, ты же кроме маркетингово булшита ничего сказать не в состоянии.

Тем более оракл рекомендует другие схемы и свой OCFS2 в подобных сценариях не продвигает.

Каких сценариях. Вот сценарий мастер-мастер или даже серьезней мастер-мультимастер. Что оракл продвигает?

Ладно. Не думаю, что ответ от тебя последует. Только покажи мне где ты вычитал, что оракл рекомендует отказываться от RAC для master-master. Все, что оракл рекомендует это учитывать факторы, один ты назвал. Тем не менее, он настолько маловероятен, но все же вероятен, да. Только вот проблем с резолвом повисших транзакций ты, наверно, словишь больше и чаще, чем пресловутые траблы в ФС.

И дело даже не в рейдах. Если у вас сервак автоматом рестартует после краха, чтобы занести пакость, то чья это проблема? Конечно же ФС. Если никто не следит за состоянием рейда, даже нотификации о вылетах не выводите, то чья это проблема? Чья проблема сразу возвращать диск в рейд после вылета не разобравшись в причине?

Но, респект, своеобразный, за буквальное понимание док. Тем не менее, те, кто не ставит вопросов поперек учителям далеко от них не уходят. А вот некоторые, такие как Лобачевский, иногда могут совершать прорывы. Только не надо думать, что я считаю себя таким. Нет. Просто сомневаться и проводить собственные замеры, тесты (о коих мне хотелось бы услышать, т.е. сколько фоллов ФС ты словил в %) по-моему неплохая черта.

Ладно. Не думаю, что ответ от тебя последует. Только покажи мне где ты вычитал, что оракл рекомендует отказываться от RAC для master-master.

Ты бы уже заканчивал заниматься демогогией и обильно словесно поносить. Пошёл бы и познакомился для начала с совсем простыми фактами и понятиями - что такоке репликация, понял бы как работает ОCFS и что на уровне этой ФС никакой репликации нет, понял бы что такое RAC и HA. Может быть тут до тебя наконец таки дошло что RAC это не master-master чтобы там не было (не репликация, например) и вообще не имеет никакого отношения к репликации.

Теоретики. Читани, на досуге: https://drbd.linbit.com/users-guide/ch-ocfs2.html А лучше, сделай сам, чтобы не позориться в след. раз.

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

Что именно почитать? Где линк на доку? Его, извиняюсь, высер о том, что OCFS не имеет никакого отношения к репликации данных вообще нонсенс. Мои глаза не врут. Делаем два сервера через OCFS+DRBD, создаем общее хранилище. Делаем запись файла на одном сервере, а на другом сервере, на его дисках этот файл появляется. Делается это все по локальной сети: два сервера тупо объеденены в сеть. Вот и вся магия OCFS в трех предложениях.

Теперь вопрос, чем это отличается от клиент-сервера и киданием файла (журнала) по той же самой сети, кроме того, что файл жует сервер бд? Тем, что это сервер бд делает, да. Это репликация. А репликация не через сервер бд это не репликация, это высер каких-то лошпетов.

Всё. Жду доков, а не пустословия о том кого слушать или не слушать.

Конкретно, мой ответ, насчет «рекомендаций не использовать RAC»:

Oracle Real Application Clusters Compared with Replication

The two major areas where you need to consider whether Advanced Replication or Oracle Real Application Clusters (Oracle RAC) better serves your needs are load balancing and survivability.


Load Balancing: Advanced Replication provides read load balancing over multiple databases, while Oracle RAC provides read and write load balancing over multiple instances. Because each write must be performed at each replication site, replication does not offer write load balancing.


Survivability: Replication provides greater survivability protection with regards to natural disasters, power outages, or sabotage, or both because the remaining replication sites can be positioned in a geographically different region. Oracle RAC operates on a cluster or other massively parallel system and is located in the same physical environment, and thus cannot protect against the physical problems that replication can protect against.


Interoperability: Advanced Replication can replicate data between different platforms and operating systems that are running Oracle. The instances in an Oracle RAC environment must run on the same platform.

Его, извиняюсь, высер о том, что OCFS не имеет никакого отношения к репликации данных вообще нонсенс.

Но ты же не понимаешь, что такое репликация.
Ты даже не знаешь значения этого слова. Не только применительно к компьютерам, а вообще - применительно к биологии, например.
Репликация - это создание КОПИЙ объекта.
Копий - это ключевое слово.
В случае же с OCFS2/ASM/RAC данные находятся в единственном экземпляре, соответственно это не репликация данных.

Конкретно на физическом уровне происходит копирование. На логическом уровне копирования, да, нету. Теперь предположим, что нас не интересует логическое копирование. Что получится? Репликация или нет?

Простите, а какой объект реплицируется на физическом уровне?

Бит, сынок, реплицируется. Бит.

Почитайте чтоли вики, может чего поймете: https://en.wikipedia.org/wiki/Distributed_Replicated_Block_Device

Конкретно (у вас-то времени искать пруфы нет, но у меня есть всегда):

Comparison to RAID-1

DRBD bears a superficial similarity to RAID-1 in that it involves a copy of data on two storage devices, such that if one fails, the data on the other can be used. However, it operates in a very different way from RAID, even network RAID.

In RAID, the redundancy exists in a layer transparent to the storage-using application. While there are two storage devices, there is only one instance of the application and the application is not aware of multiple copies. When the application reads, the RAID layer chooses the storage device to read. When a storage device fails, the RAID layer chooses to read the other, without the application instance knowing of the failure.

In contrast, with DRBD there are two instances of the application, and each can read only from one of the two storage devices. Should one storage device fail, the application instance tied to that device can no longer read the data. Consequently, in that case that application instance shuts down and the other application instance, tied to the surviving copy of the data, takes over.

Conversely, in RAID, if the single application instance fails, the information on the two storage devices is effectively unusable, but in DRBD, the other application instance can take over.

--

Конечно же, вы скажите, что это не то. К репликации не имеет никакого отношения! Верно. Вот вам анекдот сочинил [для нашего местного ботаника]:

Встречаются два студента-биолога и один другого спрашивает:
-- Как думаешь, клонирование можно считать репликацией себя?
-- Неее. Не те ощущения. С женой приятней.

Таблицы и БД вы не реплицируете значит? Только биты?

Ты лучше думай, чтобы начальство или кто из твоих друзей это не прочитали.