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

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

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

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

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

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

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

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

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

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

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

На уровне 7 практически невозможно добиться высокой доступности девяток. В конечном итоге вы получите человека A, который пытается обновить данные на узле 1 точно в то же время, когда человек B обновляет его на узле 2 ... и тогда вы потеряете узел 1.

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

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

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

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

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

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

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

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

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

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

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

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

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