Добро пожаловать в форум, Guest >> Войти | Регистрация | Поиск | Правила | | В избранное | Подписаться | ||
Все форумы / Microsoft SQL Server |
![]() ![]() |
Топик располагается на нескольких страницах: [1] 2 вперед Ctrl→ все |
JMLabs Member Откуда: Сообщений: 69 |
Возможно вопрос банальный, но почему-то не найти информацию... Суть в следующем. Есть сервер с MSSQL2008R2, там лежит база данных с активными транзакциями. Рядом в стойке есть файловое хранилище iSCSI. Очень хочется обеспечить зеркало базы на этом файловом хранилище. Типовая схема для репликации или зеркалирования подразумевает наличие второго сервера с MSSQL, а у меня фактически локальный диск. Нужно иметь мгновенную копию базы на файловом хранилище на случай выхода из строя жесткого диска сервера. Подскажите, пожалуйста, где найти рецепт такого зеркалирования? |
2 фев 17, 22:55 [20175503] Ответить | Цитировать Сообщить модератору |
Владислав Колосов Member Откуда: Сообщений: 8303 |
JMLabs, Вам нужно не зеркало, а аппаратное резервирование хранилища данных. В любом случае без остановки работы пользователей ничего толкового не выйдет. |
2 фев 17, 23:08 [20175534] Ответить | Цитировать Сообщить модератору |
JMLabs Member Откуда: Сообщений: 69 |
Готов остановить, настроить и запустить. Спокойствие за сохранность базы дороже небольшого простоя и вскриков клиентов) Куда копать? |
2 фев 17, 23:21 [20175557] Ответить | Цитировать Сообщить модератору |
komrad Member Откуда: Сообщений: 5491 |
JMLabs, расскажите поподробней про "файловое хранилище iSCSI" и пролейте свет на дисковую подсистему вашего сервера. |
3 фев 17, 00:40 [20175681] Ответить | Цитировать Сообщить модератору |
JMLabs Member Откуда: Сообщений: 69 |
Даже не очень понимаю что сказать про дисковую систему. RAID 10, обычные винчестеры (не SSD), 1 логический диск, там ОС и СУБД, место размещения баз - по умолчанию. В стойке есть NetGear 2100, у него есть протокол iSCSI, я выделил кусок дисковой системы, iSCSI инициатором подключил его к серверу, появился диск D. Вот не него я и хочу зеркалить базу. |
3 фев 17, 01:19 [20175709] Ответить | Цитировать Сообщить модератору |
Relic Hunter Member Откуда: AB Сообщений: 7480 |
|
||
3 фев 17, 02:41 [20175737] Ответить | Цитировать Сообщить модератору |
JMLabs Member Откуда: Сообщений: 69 |
Relic Hunter, мне нужна точная копия рабочей базы в любой момент времени, разве это бекап? Это зеркало |
3 фев 17, 03:17 [20175746] Ответить | Цитировать Сообщить модератору |
Dmitry V. Liseev Member [заблокирован] Откуда: Санкт-Петербург Сообщений: 5489 |
|
||
3 фев 17, 06:34 [20175797] Ответить | Цитировать Сообщить модератору |
aleks2
Guest |
Не надо давать глупые советы. Диск iSCSI - это неподходящее место для базы.
Такого рецепта нет. Нельзя построить RAID 1 из локального диска и диска iSCSI. Не изобретайте велосипед - лучше подключите еще один диск к контроллеру сервера. |
||||
3 фев 17, 07:59 [20175844] Ответить | Цитировать Сообщить модератору |
rahzer Member Откуда: Сообщений: 2297 |
Можно сделать динамический (софтовый) рэйд средствами MS, но это будет редкостный и тормозной костыль. Да и в целом выгода какая? А если материнка сдохнет, а если рэйд-контроллер? Шифровальщик и т.п. Без второго экземпляра СУБД на другом железе, вы можете рассчитывать только на бэкапы. |
||
3 фев 17, 08:15 [20175875] Ответить | Цитировать Сообщить модератору |
aleks2
Guest |
1. Ты смог ЭТО сделать? 2. Тут то какие проблемы? Это не последняя материнка и контроллер на планете. |
||||
3 фев 17, 08:52 [20175963] Ответить | Цитировать Сообщить модератору |
JMLabs Member Откуда: Сообщений: 69 |
Коллеги, поясню свою мысль чуть подробнее. Конечно RAID 10 обеспечивает хорошую надежность, но какой бы не был рейд, сам сервер может умереть, например, при очередном обновлении уйти в перезагруз и не взлететь или банально вентилятор сдохнет и сервер выключится. Вот именно в такой ситуации я бы хотел иметь возможность запасной вариант доступа к данным с другого сервера. Конечно можно завязать 2 SQL в зеркало, но я бы не хотел задействовать ресурсы SQL другого сервера, который есть в стойке, он относится совершенно к другому проекту и заказчику. Также я совершенно не хочу зеркалить весь диск C как было предложено выше. Я подумал что неплохо было бы если бы SQL умел вести запись сразу в 2 базы, тогда бы я одну из них разместил бы на диске iSCSI и в случае краша сервера имел бы доступ к данным. Вот именно о таком функционале я и спрашивал, как средствами одного инстанса SQL иметь транзакционную копию базы где-то еще. |
3 фев 17, 09:54 [20176189] Ответить | Цитировать Сообщить модератору |
Alibek B. Member Откуда: Сообщений: 3822 |
Все зависит от того, какая используется СХД. Эта функция есть у всех более-менее крупных брендов, но называется и лицензируется по разному.
iSCSI это хорошее место для базы. При правильной архитектуре и планировании это надежнее и быстрее локальных дисков. |
||||
3 фев 17, 10:17 [20176276] Ответить | Цитировать Сообщить модератору |
Alibek B. Member Откуда: Сообщений: 3822 |
В случае краша сервера можно снять с него жесткий диск и точно также получить доступ к данным. Почему именно iSCSI? |
||
3 фев 17, 10:21 [20176293] Ответить | Цитировать Сообщить модератору |
rahzer Member Откуда: Сообщений: 2297 |
Да, но, повторюсь, это был редкостный и тормозной костыль.
Ну ТС же писал:
Ну и при сдохшем контроллере и материнке, куда ТС со своим массивом будет тыкаться? Да, привезут по гарантии или новой закупке, но это сколько времени будет, а ТС нужно здесь и сейчас. Максимум можно посоветовать виртуалку - но это падение производительности, к тому же сам NAS может не сдюжить, ну и если сдохнет ОС, то в любом случае надо будет к какому-то инстансу эту данные с виртуалки цеплять. |
||||||
3 фев 17, 10:22 [20176298] Ответить | Цитировать Сообщить модератору |
Alibek B. Member Откуда: Сообщений: 3822 |
В случае зеркала (RAID1) сдохший RAID-контроллер проблемой не является. А любой другой RAID (кроме разве что RAID10) для БД использовать не стоит. |
||
3 фев 17, 10:23 [20176309] Ответить | Цитировать Сообщить модератору |
rahzer Member Откуда: Сообщений: 2297 |
В RAID-1 может быть не только 2 диска, но и более, и куда потом с дисками этими бежать? Но пусть даже и 2 диска, а они SAS, у вас много материнок поддерживают SAS диски? Хорошо, есть сервер с таким контроллером, а там есть место в корзине под этот диск? Даже если есть, точно уверены на 100%, что другой контроллер, подхватит и импортирует конфигурацию корректно?
Это если аппаратные HBA и недешевая СХД или NAS, дорогие коммутаторы и все это на 10Гб Локальные диски дешевле и быстрее.. |
||||
3 фев 17, 10:44 [20176380] Ответить | Цитировать Сообщить модератору |
leov Member Откуда: С-Петербург Сообщений: 616 |
JMLabs, вообще конечно интересно было бы иметь запасные файлы базы данных которые можно было бы подцепить к другому серверу в случае краха основного но тут надо понимать что "точная копия рабочей базы в любой момент времени" получится все равно с некоторым допущением по точности и по времени если доносить в копию абсолютно все физические изменения то вероятно что когда посыплются основные файлы то вы получите копию кривых файлов предполагаю что вы совсем не этого хотите в копию имеет смысл посылать только завершенные транзакции а это уже транзакционная репликация или логшипинг или достаточно частый бэкап логов первое и второе предполагает sql server в качестве приемника и тогда вы таки получите горячую копию базы на которую можете переключить юзеров если будет бэкап логов то вы получите большой перерыв на поиски или поднятие нового инстанса sql и поднятие на нем бэкапов это может оказаться достаточно долго вы сказали что другой sql у вас есть, дак настраивайте на него репликацию или логшипинг много нагрузки на него это не прибавит зато при сбое получите переключение в течение считанных минут |
3 фев 17, 10:46 [20176394] Ответить | Цитировать Сообщить модератору |
Alibek B. Member Откуда: Сообщений: 3822 |
Если речь идет о нормальных СХД, то в них для snapshot гарантируется консистентность данных на уровне БД. |
||
3 фев 17, 10:56 [20176424] Ответить | Цитировать Сообщить модератору |
Dmitry V. Liseev Member [заблокирован] Откуда: Санкт-Петербург Сообщений: 5489 |
|
||||
3 фев 17, 11:30 [20176603] Ответить | Цитировать Сообщить модератору |
Dmitry V. Liseev Member [заблокирован] Откуда: Санкт-Петербург Сообщений: 5489 |
Если предполагается, что сервер СУБД может сдохнуть, то надо просто хранить базы не только на локальных дисках. Есть два варианта: 1) данные хранятся на внешней хранилке и сервер имеет онлайн доступ к ним. 2) данные хранятся на локальных дисках, сервер имеет онлайн доступ к ним, но онлайн-копия данных делается на внешней хранилке. В варианте 2, поскольку это база данных, то получить онлайн-копию данных можно только имея в качестве приёмника второй sql сервер. То есть, репликация. Время на восстановление при варианте 2 минимально. При варианте 1 оно больше. |
||||
3 фев 17, 11:46 [20176688] Ответить | Цитировать Сообщить модератору |
JMLabs Member Откуда: Сообщений: 69 |
С вашего позволения подрезюмирую коллективное мнение. Задача была сформулирована так: рассматривается ситуация, когда сервер с базой данных стал недоступен (завис, не включается) при этом ехать к нему для выяснения причин времени нет, но нужно относительно быстро поднять все на другом сервере или хотя бы иметь доступ к БД. Примечание. Копия базы должна быть максимально актуальная, согласен что реплицировать логично завершенные транзакции и это механизм СУБД MSSQL который хотелось найти без использования второго инстанса MSSQL. Советы. По сути мысли разделились на 2 направления: 1. Копия на уровне файловой системы, т.е. какие-то решения типа RAID или файловой синхронизации, бекапы 2. Репликация средствами MSSQL. Тут прозвучало мнение что это возможно только имея второй инстанс. В первом случае вероятно требуется какой-то софт, который будет следить за двумя папками с файлами и все время их синхронизировать, причем не тупо, а конкрементарно (т.е. обновлять только те кусочки, которые реально изменились). Честно говоря, с трудом верится что при внезапном отключении основной базы, резервная сохранится в читаемом виде. Во втором случае вроде как хочется сделать зеркалирование само на себя, но SQL жестко отсекает такие попытки: The principal and mirror server instances cannot be the same instance of SQL Server. Select another instance as the mirror server instance. Неужели у меня такая экзотическая ситуация что нет никакого решения без костылей? |
3 фев 17, 11:49 [20176715] Ответить | Цитировать Сообщить модератору |
Владислав Колосов Member Откуда: Сообщений: 8303 |
JMLabs, географически резервирование данных требуется в особых случаях, и это не офисные системы, как правило. Поэтому резервируются диски одного хранилища. Второе, что резервируются - это серверные платы. В Вашем случае есть опасения только о выходе из строя единственного жесткого диска с базами. Поэтому и было рекомендовано резервировать диски. Оптимальный способ (минимум накладных расходов на сопровождение) - использовать RAID массив с возможностью "горячей" замены. |
3 фев 17, 12:23 [20176906] Ответить | Цитировать Сообщить модератору |
komrad Member Откуда: Сообщений: 5491 |
заведите локальный алиас на ваш сервер, но с другим именем попробуйте настроить зеркало на алиас |
||
3 фев 17, 13:15 [20177232] Ответить | Цитировать Сообщить модератору |
alexeyvg Member Откуда: Moscow Сообщений: 31778 |
Если вам достаточно иметь данные отдельно от сервера, тогда не нужно зеркала, отсоединили рабочий диск, и перенесли на другой сервер. Ну и бакапы нужны, независимо от наличия любых зеркал. Бакап - это тоже ваша копия данных, восстановили на любой момент времени где угодно, и используйте на здоровье. Т.е. вы хотите то, что уже есть, но что бы называлось по другому? Это не возможно, просто изучите и применяйте имеющиеся возможности. |
||||
3 фев 17, 14:04 [20177504] Ответить | Цитировать Сообщить модератору |
Топик располагается на нескольких страницах: [1] 2 вперед Ctrl→ все |
Все форумы / Microsoft SQL Server | ![]() |