читать по разному, но скорее всего все сразу. Писать и добавлять. А еще удалять по одному. Разные варианты, иначе вопрос бы не имел смысла.
Вопрос СЕЙЧАС не имеет смысла - потому что не сказано вообще ничего вменяемого (в том числе и в комментариях к данным уже ответам). Даже точной версии MySQL - и то не указано. А потому любые советы в нынешнем состоянии вопроса - не более чем тыкание пальцем в небо. И рассчитывать на то, что любой совет из данных на основании имеющегося никакого описания окажется оптимальным - это верх оптимизма.
Впрочем, нам-то как раз пофиг - это у Вас потом возможны проблемы из-за неверно выбранной стратегии.
Всё верно. Но в любом варианте есть теоретическая ситуация, приводящая к рассинхрону. Да, при синхронной репликации её вероятность на порядки меньше - именно за счёт производительности.
paran0id, вообще-то есть. Удалить содержимое и сохранить пустой файл можно только сознательно, тогда как для того, чтобы смахнуть файл мышом в корзину (или чаще - переместить в соседний каталог), достаточно просто кривых рук и выключенного мозга. Я с таким сталкиваюсь в среднем 2-3 раза в месяц...
Nabi Alimetov, ну зачем так сразу? вы хотя бы сначала поищите, почитайте... бесплатные решения имеются. Кстати, некоторые устройства (например, сетевые накопители) имеют такую функцию изначально в своём внутреннем ПО. И я бы рекомендовал именно такое решение, а не просто шары с локальных дисков.
Дурь с созданием отдельной учётной записи, от имени которой запускается Word, с сохранённым, но неизвестным пользователю, паролем - не рассматривать?
Впрочем, он всё равно сможет удалить - из любого диалогового окна Word...
WITH cte AS (
SELECT timestamp t_from, LEAD(timestamp) OVER (ORDER BY timestamp) t_till
FROM sourcetable
)
SELECT *
FROM cte
WHERE t_till - t_from > '00:10:00'
С другой стороны - ну глупо половинить полосу пропускания и по одному и тому же порту гонять тот же трафик сперва туда, в потом оттуда. Пусть трафик от ISP идёт на один порт Микротика, а раскиданный для LAN - через другой порт. Всё одно они на Циске в разных VLANID, так что не заштормит.
Ну и нет никакого смысла делать виланы на Микротике, если весь LAN - это один VLANID.
Полное шифрование накопителя с использованием внешнего аппаратного ключа. При загрузке со стороннего носителя ничего извлечь, тем более поменять, не получится.
А роутер-то ему зачем? эти функции выполняет сам межсетевой экран, если нужно, это у него штатная функция.
Хотя да, функцию роутера (первичного NAT-преобразования), если это действительно требуется, выполнит маршрутизатор. Допустим, трафик из каждого VLAN будет NAT-иться через отдельный промежуточный адрес - для упрощения составления правил фильтрации и приоретизации внешнего трафика и получения раздельной статистики доступа в Инет. Хотя как по мне - лишнее это, проще создать соответствующие группы на экране.
Вася Пупкин, ну да. В принципе каждый должен заниматься своим делом. Маршрутизатор - маршрутизирует, экран - экранирует...
Опять же - ну зачем тебе гонять внутрисетевой трафик через экран? представь, что ты бэкапишь виртуалку, или там экспортируешь запись с видеосервера, или ещё что сильно-объёмное... и вот весь этот многогигабайтный массив у тебя летит через сетевой экран. Да фиг кто в это время достучится до Инета...
Вы что, хотите и внутрисетевой трафик проверять средствами экрана? если да, то, конечно, пусть выполняет роль и роутера, и экрана.
А если нет - то используйте отдельный маршрутизатор. Заодно это позволит канал наружу, что между клиентами сети и Инетом, пустить через отдельный VLAN, и не иметь на клиентах прямой доступ к экрану.
Максим Гришин, это вполне возможно. Даже с точки зрения надёжности два непересекающихся DHCP в одном вилане лучше одного.
Вот если скоп перекрывает всю подсеть
Необязательное условие. Всё же есть часть адресов подсети, которые должны назначаться именно статически, где простого резервирования адреса недостаточно. Скажем, те же GW и DNS, адреса которых передаются клиентам.
Вопрос СЕЙЧАС не имеет смысла - потому что не сказано вообще ничего вменяемого (в том числе и в комментариях к данным уже ответам). Даже точной версии MySQL - и то не указано. А потому любые советы в нынешнем состоянии вопроса - не более чем тыкание пальцем в небо. И рассчитывать на то, что любой совет из данных на основании имеющегося никакого описания окажется оптимальным - это верх оптимизма.
Впрочем, нам-то как раз пофиг - это у Вас потом возможны проблемы из-за неверно выбранной стратегии.