уничтожьте SIGABRT, не генерирует базовый файл от демона, запущенного с crontab
Я думаю, что у Вас есть часть Вашей перепутанной терминологии.
При установке SQL Server Вы обычно устанавливаете экземпляр механизма базы данных. Экземпляр механизма базы данных может содержать много отдельных баз данных. Экземпляр может быть установлен на автономном сервере или отказоустойчивом кластере окон.
Можно установить несколько экземпляров механизма базы данных на данном сервере или отказоустойчивом кластере. В кластерном сценарии каждый экземпляр может только работать на одном узле за один раз. Однако можно переместить все экземпляры в тот же узел, если Вы хотите.
Я думаю, что Вы пытаетесь спросить, можно ли выполнить несколько экземпляров механизма базы данных на единственном кластере. Ответ - да. Можно выполнить столько, сколько аппаратные средства будут поддерживать.
Если я понимаю Ваш разъясненный вопрос, Вы спрашиваете, возможно ли зеркально отразить единую базу данных через несколько различных серверов и затем загрузить запросы баланса через зеркала. Я думаю, что ответ нет. Можно установить базу данных, зеркально отражающую достаточно легко. Но я не думаю, что существуют любые функции балансировки загрузки запросов из поля. Мог бы быть сторонний продукт, который может обработать это все же.
Текущий рабочий каталог для задания крона может отличаться, чем то, которое Вы ожидаете. Попытайтесь делать cd /some/writeable/dir && yourdaemon в Вашей crontab записи. Кроме того, необходимо обычно выполнять deamons, использующий init или Выскочку или подобный. Посмотрите управление процессами.
От man 5 core:
Существуют различные обстоятельства, при которых файл дампа ядра не является про ‐ duced:
Процесс не имеет разрешения записать базовый файл. (По умолчанию базовый файл называют ядром и создают в текущем рабочем каталоге. Посмотрите ниже для получения дополнительной информации об именовании.) Запись базового файла перестанет работать, если каталог, в котором это должно быть создано, будет неперезаписываем, или если файл с тем же именем существует и не перезаписываем или не является регулярным файлом (например, это - каталог или sym ‐ bolic ссылка).
(Перезаписываемый, регулярный) файл с тем же именем, как использовался бы для дампа ядра уже, существует, но существует больше чем одна жесткая ссылка на тот файл.
Файловая система, где файл дампа ядра был бы создан, полна; или исчерпал inodes; или смонтирован только для чтения; или пользователь достиг их квоты для файловой системы.
Каталог, в котором должен быть создан файл дампа ядра, не существует.
RLIMIT_CORE (базовый размер файла) или RLIMIT_FSIZE (размер файла) пределы ресурса для процесса обнуляются; см. getrlimit (2) и документация команды ulimit оболочки (предел в csh (1)).
Двоичный файл, выполняемый процессом, не имеет разрешения чтения включенным.
Процесс выполняет идентификатор пользователя набора (идентификатор группы набора) программа, которая принадлежит пользователю (группа) кроме реального пользователя (группа) идентификатор процесса. (Однако см. описание prctl (2) операция PR_SET_DUMPABLE и описание/proc/sys/fs/suid_dumpable файла в proc (5).)