Как добиться нулевого времени простоя

Нет такого понятия, как нулевое время простоя. Установите реалистичную цель (скажем, пять девяток безотказной работы) и планируйте ее. Если вы достигнете своей цели, отличная, но обещающая, что система никогда и никогда не выйдет из строя, вы можете поймать вас в состояние, в котором невозможно провести значительные архитектурные обновления, необходимые для продолжения обслуживания системы при разумных затратах.

Основным соображением для нулевого (или близкого к) времени простоя является количество операций обновления. Обновления (и удаления) конфликтуют способами, которые вставки не делают.

Уровень 1. База данных практически полностью доступна только для чтения (например, используется для системы управления контентом). Это самый простой для копирования.

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

Уровень 3. Вставляет только сегментированные (например, один узел принимает обновления для Америки, другой для Европы, третий для Азии...).

Уровень 4. Вставляет / Обновляет / Удаляет на одном узле, который распределяется на другие узлы "только для чтения".

Уровень 5. Вставляет / Обновляет / Удаляет черепки (например, один узел принимает обновления для Америки, другой для Европы, третий для Азии...).

Уровень 6. Вставляет на нескольких узлах, распределенных по всем другим узлам.

Уровень 7. Вставляет / Обновляет / Удаляет на нескольких узлах, распределенных по всем другим узлам.

На уровне 6/7 я буду искать решения для NoSQL. Может быть, 3 и 5 уровня, если я думаю, что механизм шардинга не будет устойчивым в течение более длительных периодов времени.

Уровень 7 практически невозможно достичь высокой доступности девяток. В конечном итоге вы получите человека А, пытающегося обновить материал на узле 1 в то же самое время, когда человек Б обновляет его на узле 2.... и тогда вы потеряете узел 1.

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

Несколько дизайнерских идей:

• Используйте SYS_GUID для создания всех ваших первичных ключей вместо последовательности, которая может создавать дубликаты ключей, если вы не будете осторожны.
• Избегайте удалений, так как они, по-видимому, вызывают самые большие головные боли для ошибок ссылочного ограничения при репликации.
• Попробуйте сгруппировать транзакции, которые могут помешать каждой из них в одной базе данных, и переходить к альтернативной только в случае сбоя одной из них.
• Тщательно используйте уникальные ограничения, так как они также приводят к большим ошибкам репликации.

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

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

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

Для главного / подчиненного ChronicDB может выполнять оперативные обновления с учетом репликации без несоответствий.

Так что проблемы между active-active и master-slave, и для обоих есть хорошие альтернативы

Самый простой способ добиться активной / активной конфигурации в Oracle - использовать Oracle RAC (Real Application Cluster). Документацию RAC можно найти здесь.

RAC также можно комбинировать с другими инструментами Oracle High Availability, такими как Data Guard или Streams. Документация HA доступна здесь.

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

Поможет ли введение облака Cassandra/HBase(или любого другого без SQL dbs) в нулевое время простоя, или это только для быстрого поиска данных в большой базе данных?

Cassandra может помочь, потому что она позволяет даже существенные обновления происходить через повторяющиеся перезапуски (каждый узел обновляется последовательно). Большинство хороших библиотек Cassandra поддерживают автоматическую отправку запросов доступным узлам при внесении изменений в кластер. Использование коэффициента репликации 3 и уровня согласованности "кворум" позволяет обеспечить бесперебойную работу посредством повторных перезапусков даже при сохранении согласованности.