Пасечник Кузьмич,
ну справедливости ради не копии таблицы. Копии - это репликация, при шардинге на разных хостах данные разные. По сути происходит "размазывание" таблицы на несколько серверов. По сути партицирование, но не на одном сервере, а на нескольких. Однако соглашусь, что задачу топикстартера решит именно партицирование, сервер то в задаче 1.
hOtRush, lapka-admin,
да, при "смерти" мастера слэйв промоутится до мастера. Относительно классический вариант - при этом отрабатывает какой-нибудь HA и IP также переезжает на slave.
vldud, git в этом образе лежит в /usr/bin/git.
так что тогда уж
volumes:
- "/usr/bin/git:/usr/bin/git"
но это наверняка не заработает, либ не хватит
сделайте уже Dockerfile
FROM nanoninja/php-fpm:7.2.2-fpm
Александр, конечно одна из постулируемых главных фичей контейнеризации это самодостаточность контейнера.
однако возможность на этапе отладки что-то подложить в контейнер или поправить в нем руками вместо пересборки каждый раз зачастую ОЧЕНЬ ускоряет процесс. К слову чем принципиально отличается конфиг или данные БД, монтируемые снаружи, от бинаря? что без первого, что без второго работа контейнера будет либо невозможна, либо сильно отличаться от варианта С файлом-конфигом-данными
тогда надо его "прокинуть" внутрь.
вот как у Вас конфиг php прокинут
- "./etc/php/php.ini:/usr/local/etc/php/conf.d/php.ini"
тогда он станет доступным внутри контейнера. На сколько я понимаю связь nginx-php, класть надо в контейнер к php.
да, еще учтите, одного бинаря может быть мало, он может захотеть видеть и какие-то либы. Возможно правильнее будет собрать свой образ с этим пакетом, делов на 5 минут
но тогда пакет внутри контейнера и снаружи могут разъехаться при обновлении
Константин Цветков, зачем? в результате то все равно выполнится EXPLAIN. И даже Ваша волшебная кнопка "отладка" сделает ровно то-же самое. Т.е. независимо от БД можно научиться пользоваться 1 командой - или под каждую БД искать "средство разработки", в котором эта-же команда будет выполняться нажатием 1 кнопки.
Я понимаю, что в отсутствии человеческой консоли приходится пользоваться "средствами разработки". Но это не везде так.
LODIII, ну что ж, крупно не повезло. Хотя тезис "банковская ИБ - трэш и угар" поддержу. Но ведь на этой части ИБ свет клином не сошелся, есть суперское направление SOC-ов, есть поиск уязвимостей, для мега-зануд есть аудит. Да даже и в ТЗКИ можно найти кучу интересных задач.
начальник скорее всего из бывших фсбшников, со своим "складом" ума
у меня их по-очереди было 3 ФСБшников, а потом еще и бывший опер. Все как минимум очень приличные люди, а опера я так вообще с огромной симпатией вспоминаю.
Ну и главное -Вам придется следить за людьми, читать их почту, переписки в месенджерах, анализировать куда они заходили на сайты итп.
ну это Вы очень круто погорячились. Наверняка где-то и таким трэшем занимаются, но, поверьте, даже в очень зарегламентированной банковской ИБ это не делают. Хотя бы просто потому, что закон немножко не разрешает. DLP - это да, но там во первых анализ данных автоматический, во вторых больше технической работы. К слову весьма нескучной. Ну а расследование инцидентов вааще сказка =)
Chvalov, формула врядли, скорее уж здравый смысл.
вот смотрите, в постгре данных всего 12Гигов. значит вот прямо сейчас отдавать под кэш в него более этих 12 гигов особого смысла нет, постгре они не помогут. т.е. уже память пополам делить смысла нет. Однако он, по Вашим словам, основной источник данных.
В мускуле данных изрядно. на секундочку в 20 раз больше. однако всего памяти 32, БД мускуля хоть упрись в память не загрузишь.
значит будем искать компромис.
Я бы начал с того, что отдал бы 12 гигов под shared_buffer Postgres-а, effective_cache_size - еще 4Г. из оставшихся 16 12г под innodb_buffer_pool, гиг по мелочи между остальными буферами мускуля.
дальше подождал бы день-два и посмотрел на кеш-хит-рэйт
ну справедливости ради не копии таблицы. Копии - это репликация, при шардинге на разных хостах данные разные. По сути происходит "размазывание" таблицы на несколько серверов. По сути партицирование, но не на одном сервере, а на нескольких. Однако соглашусь, что задачу топикстартера решит именно партицирование, сервер то в задаче 1.