xmoonlight: Видео входит в состав компа. И если проц работать не будет - процесс запуска не дойдет даже до POST-а, не говоря уже об инициализации видео. Видеокарту в этом случае даже можно вытащить, и вообще ничего при этом не изменится. Но проблема ведь изначально в сокете, на это я и обращаю внимание.
Да, действительно. Но можно взять другую модель, которая не должна повлиять на суть таблицы:
CREATE TABLE `logs2` (
`INSERT_DATE` timestamp DEFAULT NULL DEFAULT CURRENT_TIMESTAMP,
`DATA` text NOT NULL,
KEY `INSERT_DATE` (`INSERT_DATE`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8
/*!50100 PARTITION BY RANGE (unix_timestamp(insert_date))
(PARTITION p20150313 VALUES LESS THAN (unix_timestamp('2015-03-14 00:00:00')) ENGINE = InnoDB,
PARTITION p20150314 VALUES LESS THAN (unix_timestamp('2015-03-15 00:00:00')) ENGINE = InnoDB,
PARTITION p20150315 VALUES LESS THAN (unix_timestamp('2015-03-16 00:00:00')) ENGINE = InnoDB,
PARTITION p20150316 VALUES LESS THAN (unix_timestamp('2015-03-17 00:00:00')) ENGINE = InnoDB,
PARTITION pmaxval VALUES LESS THAN MAXVALUE ENGINE = InnoDB) */
Здесь всё работает. Результат:
mysql> EXPLAIN PARTITIONS SELECT INSERT_DATE, DATA from logs2 WHERE INSERT_DATE >= '2015-03-15' AND INSERT_DATE < '2015-03-16'\G
*************************** 1. row ***************************
id: 1
select_type: SIMPLE
table: logs2
partitions: p20150315
type: range
possible_keys: INSERT_DATE
key: INSERT_DATE
key_len: 4
ref: NULL
rows: 1
Extra: Using where
1 row in set (0,00 sec)
Или другой вариант, который теперь уже даже проще:
mysql> SELECT * FROM `logs2` PARTITION (p20150315);
+---------------------+------+
| INSERT_DATE | DATA |
+---------------------+------+
| 2015-03-15 00:00:00 | bla1 |
| 2015-03-15 03:00:00 | bla2 |
+---------------------+------+
2 rows in set (0,00 sec)
Ну и в конце:
ALTER TABLE `logs2` DROP PARTITION `p20150313`;
ALTER TABLE `logs2` ADD PARTITION (PARTITION p20150317 VALUES LESS THAN (unix_timestamp('2015-03-18 00:00:00')));
только pmaxval мешает добавлять очередные дни. Впрочем, можно или убирать/добавлять его каждый раз для подстраховки, или если скрипт будет четко выполняться каждый день, то и вообще убрать pmaxval за ненадобностью. Или накрайняк создать их на неделю вперед и не париться
Ну как сказать, СОРМ жив-здоров :) нет трафика - реагируют быстро, соединения все просматриваются и пишутся, а вот если нужны паспортные данные того, чей IP был на тот момент - уже делают запрос
У меня так реализовано на Zabbix. Когда места не хватает - просто дропаю партишн со старыми данными, и дело в шляпе. При чём, это происходит незаметно для самого ПО. И выборку, кстати, тоже можно по конкретным партишнам делать, что тоже несколько ускоряет процесс
>завести порт админа во все нетэгированые виланы
Нетегированный вилан на порту может быть _только один_, остальные должны быть с тегом. Иначе как входящий на порт трафик разделить по виланам? Нужно или несколько сетевух (для untagged), или одна с поддержкой виланов (для tagged).
>Я упорно думаю над способом выкрутиться из ситуации, не обрезая сеть на подсети
Простого варианта этого добиться нет. Или разделять на подсети, или фильтровать трафик на оборудовании, которое это умеет, но для этого нужно, чтобы все компы и сервера были вставлены в единственную железку, и придумывать кучу правил, в которых потом легко будет запутаться
>если на виланах не задавать айпишники - то видеть друг друга никто не сможет
Вилан - это считай отдельное обособленное от других виланов пространство. В тупо созданном вилане может работать 2-3-4 компа, но если нужно ходить между виланами или в инет, то придется делать шлюз
>А если будет так:
Опять же, так сделать просто не получится, коммутатор или не даст, или не будет правильно работать с такой настройкой
>Остальные порты не в вилане
Если портам не указан вилан - они работать не будут, входящие на порт пакеты просто наткнутся на пустоту вместо дальнейшей обработки. Нужно, чтобы хоть что-то было. На сброшенном по умолчанию коммутаторе все порты находятся в 1-м вилане, поэтому и работают из коробки
asdz: Когда в большой таблице меньше полей - она и весит меньше, и искать/обрабатывать проще.. в любом случае это даст прирост производительности в хайлоаде, если он будет иметь место.. а если же планируется таблица а 2-3к записей, то конечно заморачиваться не надо :)
ximik777: GROUP_CONCAT здесь просто не подходит, т.к. объединяет поля в _одну_ строку, а UNION в общем-то справляется с задачей, если побить запрос. Но чем же он не подходит?
2 селекта по индексам будут выполняться ничуть не дольше, когда база разрастется до гигабайт (а с таким составом полей она может быстро разрастись). Да и соединить - это вообще не проблема. Пара лишних миллисекунд (если не меньше) ничего не решит.
>3 вилана - порты 11+12, 21+22 и 31+32, но при этом был некий порт 40, где будет комп админа, который будет иметь возможнсть "ходить" всюду
Ладно, распишу :)
port 11,12 - vlan 100 untagged
port 21,22 - vlan 101 untagged
port 31,32 - vlan 102 untagged
port 40 - vlan 103 untagged
ACL:
deny ip 192.168.0.0/24 192.168.1.0/24
deny ip 192.168.0.0/24 192.168.2.0/24
deny ip 192.168.0.0/24 192.168.3.0/24
deny ip 192.168.1.0/24 192.168.0.0/24
deny ip 192.168.1.0/24 192.168.2.0/24
deny ip 192.168.1.0/24 192.168.3.0/24
deny ip 192.168.2.0/24 192.168.0.0/24
deny ip 192.168.2.0/24 192.168.1.0/24
deny ip 192.168.2.0/24 192.168.3.0/24
deny ip 192.168.3.0/24 192.168.0.0/24
deny ip 192.168.3.0/24 192.168.1.0/24
deny ip 192.168.3.0/24 192.168.2.0/24
эти правила запрещают хождение всего трафика между виланами 100, 101 и 102 (заметь, в правилах указываются не виланы, а подсети, из которых уже в процессе вычисляются виланы!), но не запрещают всем взаимно видеть админа в 4-й подсети, т.к. нет правил, запрещающих это.
P.S. номера виланов и сети взяты от балды, а вообще могут быть любыми в доступных пределах.
Деление сети на виланы делается далеко не только, чтобы они "не видели" друг друга. На самом деле эта "невидимость" лишь один из эффектов. По сути, 2 vlan работают в точности как 2 разных неуправляемых свича, НЕ соединенные парч-кордом, в которые подключены разные компы. В одном свиче живет подсеть, скажем, 192.168.0.0/24, в другом - 192.168.1.0/24. Что нужно, чтобы быть одновременно в 2х сетях? Есть 2 варианта:
1. кинуть 2 патч-корда к компу от обоих свичей, воткнуть в 2 сетевухи у себя на компе, настроить на одной сетку .0.0, на другой .1.0 соответственно, и сидеть видить их всех и радоваться жизни. Но допустим внезапно у нас обе сети (считай, в разных свичах или виланах) - 192.168.0.0/24. Как твой комп определит, где реально находится айпишник, скажем, 192.168.0.37? В какую сетевуху надо отправлять пакет? А ведь он не может догадаться, он может это только вычислить! А вычислить-то не может, т.к. одно и то же и там, и там.. Так вот, здесь начинается конфликт: нельзя, чтобы на 2 разные сетевухи была настроена одна и та же сеть. Винда, например, в этом случае гневно ругается. Поэтому идеологически не правильно в разных виланах делать одно и то же адресное пространство. Подсети должны быть везде разные, иначе захочется что-то объединить, и придется полностью переделывать структуру сети, что не является правильным проектированием сети тру-одмином :)
2. Поставить роутер, воткнуть в него 2 патч-корда из тех свичей, в одной сети дать ему айпишник, например, 192.168.0.1, в другой - 192.168.1.1, после этого - на всех компах прописать шлюзом этот роутер (конечно же тот айпишник, который соответствует сети компа), и через роутер эти 2 подсети будут успешно общаться и видеть друг друга. А дальше уже можно извращаться: добавить сеть 192.168.3.0 и прыгнуть туда своим админским компом, и опять же радоваться :)
Так вот, описывая эти ситуации виланами, а не на свичами - первый вариант - это тегированные виланы на одну сетевуху админа (либо 2 нетегированных порта патчами с одного свича на 2 сетевухи админа), а второй вариант - просто 1 нетегированный линк с отдельной (.3.0) подсетью, когда на свиче настроены IP интерфейсы в каждом из виланов. Но здесь есть подводный камень: свич сам должен уметь L3 помимо L2, чтобы иметь возможность создавать маршрутизируемые интерфейсы в нескольких виланах, иначе он будет уметь только виланы без интерфейсов, а объединять их придется внешним роутером!
По сути в примере со свичами то же самое, только физически реализация разная :)
Второй вариант в несколько раз лучше, но тянет за собой необходимость настройки фаервола на этом роутере. Компы в пределах свича конечно всегда будут видеть друг друга, но если не надо, чтобы сеть 192.168.0.0/24 не видела 192.168.1.0/24 - на РОУТЕРЕ создаётся правило вида "deny 192.168.0.0/24 192.168.1.0/24" и в другую сторону, вешается на один или оба интерфейса, и сети друг друга видеть перестают, однако админ в сети 192.168.3.0 их прекрасно видит, и они видят админа.
В первом варианте конечно можно сделать подобный эффект, но это надо настраивать на компе админа функции роутера, а это уже совсем другие дебри.
>"Пожалуйста, обрисуйте что нужно"
Вот, в принципе всё это соединяется интерфейсами роутера и настройкой шлюзов, и по умолчанию будет разрешен любой трафик. Остается просто подумать, кто что не должен делать, и правилами фаервола (обычно в коммутаторах называются Access-list) позапрещать всё что не надо.
11. Да, приставка "un" - что-то вроде "не". Без тэга может быть только один вилан, т.к. иначе будет непонятно, какой трафик каким виланом метить
12. Чтобы ПК понимал трафик с тэгом, ему нужно уметь обрабатывать метки на уровне драйверов. Если он это не умеет - тэгированный трафик он не увидит. Но можно указать, что в 1 и 2 портах вилан №1 без тэга, а в 3 и 4 портах - вилан №2 без тэга, и компы, вставленные в 1 и 2 порт будут видеть друг друга, но никак не увидят тех, кто вставлен в 3 и 4 порты. Ну и наоборот. Сам же тэг нужен ТОЛЬКО тогда, когда по одному порту надо отправить 2 и более виланов. Просто чтобы не путались.
13. Технология виланов стандартизирована (802.1q) и любое оборудование, которое умеет виланы, совместимо с другим оборудованием, которое тоже их умеет. Не важно, какой производитель, главное, чтобы у вилана office2 был некий ID, который был одинаковым _на обоих_ коммутаторах. Ну и с boss та же песня.
14. Ты сам задаёшь, какие виланы и как будут видны на порту. Если ты указал, что на порт выходит только 15-й вилан, то злоумышленник, подключенный к этому порту, не получит доступ ни в 3-й вилан, ни в 500-й, ни в какой, кроме 15-го. Если конечно злоумышленник будет знать логин/пароль от коммутатора, он может посмотреть какие там виланы, нужные вывести в свой порт, и только после этого получить к ним доступ. Но это уже проблема изоляции интерфейса управления.
15. Нет. Если в разных виланах будет одинаковая подсеть, то компьютеры из этих виланов никогда не увидят друг друга между виланами. Разные подсети используются только для того, чтобы можно было "попасть" друг к другу через маршрутизацию, т.к. при разных сетях не будет никаких конфликтов. В общем, одинаковые сети создают много проблем :)
"Быстрая" подмена файлов, особенно разного размера, всегда создаёт дополнительную фрагментацию, при чем на любой файловой системе. Для ISO-образа, если есть в планах его прожиг на диск, это может в итоге создать трудности и необходимость уплотнения данных как раз "долгим" методом, с проходом по всему образу.
Сергей: Ни разу за всю жизнь не встречал ни одной утилиты, монтирующей образ на запись. Обычно для этого как раз использовались папки (в каком-либо виде) и конвертация, даже в самых изощренных и экзотических решениях. Ну, надеюсь я ошибаюсь, и такой софт мне просто не попадался среди множества перелопаченных утилит :)
Сергей: Да, не сошелся, но вот так перезаписывать куда лучше в плане сжатия, чем изменять имеющиеся (а они обязательно будут изменяться, т.к. это обновления)