Зеркальное отражение по сравнению с репликацией
попробуйте это:
import re
s='valoirfinalieMONT:23maning '
print(re.findall('(mont)\D*(\d*)', s, re.IGNORECASE))
регулярное выражение будет захватывать 'mont' любое количество нецифровых (\ D) символов, а затем любое количество цифр (\ d)
игнорирование добавлен регистр, поэтому mont, MONT и MoNt, и такие тоже будут записаны
3 ответа
Оказывается, что База данных mirroing предотвращает данные, к которым получат доступ непосредственно, зеркальные данные только доступны через снимок базы данных, таким образом, отчеты от данных снимка не будут актуальны так, я буду использовать Репликацию транзакций Базы данных для обеспечения высокой доступности и выравнивания нагрузки.
Это зависит на уровне (горячий, теплый, холодный) резервной доступности, которой Вы требуете.
Различные механизмы в SQL Server обеспечивают дублирование уровня базы данных, такое как резервное копирование/восстановление, передача журналов и зеркальное отражение базы данных (в SQL Server 2005 и позже). Зеркальное отражение базы данных является единственным механизмом, который предоставляет точную копию в реальном времени защищенной базы данных с гарантией нулевой потери данных (когда зеркало синхронизируется).
Зеркальное отражение базы данных работает или в синхронном или в асинхронном режиме. При асинхронной операции транзакции фиксируют, не ожидая зеркального сервера для записи журнала в диск, который максимизирует производительность.
Это Техническое описание MS, Обеспечение Высоконадежного Зеркального отражения Базы данных использования, касается диапазона сценариев.
Необходимо, вероятно, прочитать эту статью TechNet, База данных, Зеркально отражающая Соображения Производительности и Лучшие практики.
Я не знаю SQL Server 2005, но для общего Использования SQL я всегда предпочитал бы Репликацию. Необходимо разделить чтения/записи в приложении (для MySQL существует MySQL Proxy, который может сделать это способом прокси к Вам), но получите масштабируемую систему. (чтения к ведомому устройству (устройствам), пишет в ведущее устройство),
Зеркальное отражение репликации основного ведущего устройства средств, которая приводит к проблемам параллелизма/транзакции. Даже в основных основных сценариях Вы никогда не должны отправлять запросы записи на различные серверы. В зависимости от размера Вашего проекта следующие шаги добавили бы больше ведомых устройств, и затем добавлять другого master+its ведомые устройства для дублирования.
master --- master
| |
slave slave
| |
slave slave
| |
slave slave
Даже затем Вы только отправили бы запросы записи одному ведущему устройству, но в случае провального ведущего устройства Вы могли автоматически способствовать второе ведущее устройство своей новой цели запроса записи.