Dram, разницы не увидите.
RAM-кэш актуален для горячего контента. Который очень часто меняется. Например это актуально для онлайн-кинотеатров, где популярность роликов резко вспыхивает и через день угасает, они удаляются из кеша и помещаются свежие. А так - linux очень грамотно пользуется RAM , в 99% случаев не нужно ОС мешать это делать.
Если вы уж хотите познать дзен, то дам ряд бесплатных советов:
- вся оптимизация сводится так или иначе к коду.
- не существует магических манипуляций, которые ускорят сервер в N раз.
- любая оптимизация серверных настроек дает 10-30% прироста производительности. Если фиговый код - не поможет ничего.
Лайфхак от пупсега - меньше считайте в БД. Это очень любят современные CMS . Максимум статистики, все пихаем в базу, каждый хит, каждый переход. Это же так удобно для аналитики.... А потом выясняется, что БД тормозит люто от всяких select count(). Уберите все не нужное из БД и все.
после выборов президента РФ 18 марта , вплоть до ноября 2018 года никаких всплесков не будет.
будем ходить в коридоре 57-62 туды сюды.
Те, кто торгует миллионами рублей - смогут заработать. Те, кто пытается спекульнуть парой сотен тысяч рублей, надеясь на хз-что... им рекомендую сходить в ресторан и снять хорошую проститутку.
PS: ушел в валюту, недвижимость. возвращаться не планирую. Сбереженное - кладу в валюту, на остальное живу. Как всегда ... - по любому курсу.
Особо упоротым рекомендую биткойн :)
Деньги не пахнут. Майнинг - значит майнинг.
Все то, что не легально - запрещено. Все остальное - можно. Это бизнес, а не этика.
Для затравки:
- почему некоторые переводы с карты на карту ,используя сервис p2p (person to person) от отправителя до получателя доходят не сразу?
Ответ: Потому что банк-отправитель, инициируя транзакцию, блокирует средства на счете отправителя, а не списывает их со счета. Отправляет транзакцию зачисления средств на счет получателя. Банк-получатель транзакцию получает, помечает ее у себя. Далее ждет от банка-отправителя подтверждения.
Т.е. реальной межбанковской проводоки (списание реальных средств со счета отправителя) денег с коррсчета отправителя на коррсчет получателя. Как только эта проводка прошла,банк-получатель видит у себя на коррсчете деньги, то он делает зачисление на счет получателя и средства становятся доступными для получателя. Получатель может ими пользоваться. Ожидание подтверждения занимает время. Обычно - сутки или больше.
Кто грешит ? - Сбербанк. Почему? - Сбер отдельная планета. Ему можно все. Рассказывать долго. А ведь так нельзя !!???.... - нельзя. Противоречит большинству правил большинства платежных систем. Получатель должен средства сделать доступными максимум через пол-часа. Но сбер клал на regulation rules от платежных систем.
Банку все-равно, кого эквайрить (обслуживать). Банк , имеющий лицензию на интернет-эквайринг (прием пластика на сайте клиента), даст доступ , грубо говоря, в свое API для сайта магазина. Далее этот магазин принимает оплаты с карт по всему миру. Никаких проблем не будет. Для банка - это транзакция, не более. Банков с лицензией на интернет-эквайринг в РФ - с десяток. Их не много. Тема эта не простая и муторная. Не все хотят связываться.
Как это ЮрЛицо, владеющее этим интернет-магазином, будет доставлять товар, менять товар и т д - банку все-равно. Для СБ банка , при проверке и подключении к услуге интернет-эквайринга для магазина главное, что бы ЮЛ - реально существовало, что бы товар - реально существовал, что бы на сайте было ясно и понятно описано , как товар вернуть, как его обменять, как его забраковать и т д. Зачисления будут происходить в рублях по курсу конвертации. Если нужна валюта, то , возможно, ВЭД и все дела, с этим связанные.
По ряду причин российские банки не любят эквайрить магазины, торгующие "аккаунтами", "стим", "кодами","лицензионными ключами" и бла бла бла . Т.е. цифровые товары. За исключением их полной легальщины, например ключи для антивирусов и тому подобное. Если же вы торгуете , ну , например покрышками для машин - то нет никаких проблем.
Проблемы с плательщиками ? в каком смысле возврат ? рефанд ? чаржбэк ?
Для того, что бы клиент оспорил операцию - ему необходимо инициализировать диспут в платежной системе , подав на это заявление в свой банк. Это платная процедура. Не дешевая. Открывается расследование. Арбитр - ПС (MasterCard, VISA, JCB, etc...), стороны - магазин и кардхолдер. Надлежащие качество товара определяют другие, законом закрепленные, органы. Банки могут только выяснить корректность, безопасность и правильность операции.
Иными словами - такой вакханалии как в пайпале , который полностью на стороне покупателя, в этом случае - нет. Если жалоб будет очень много - то это отдельный разговор. "Мне привезли битый планшет, верните деньги" это даааааалеко не так просто, как это кажется со стороны для пользователей ebay, aliexpress и т д. Все эти риски между покупателями и продавцами несут именно эти площадки, а не их банки.
PS: российские банки не процессят порно, эскорт, секс-шопы (хотя альфа .... милая альфа ..) , прочую черноту. Если же вы хотите продавать легальный товар, вы - реальный продавец, имеете реальный товар, обслуживаете своих покупателей - то не вижу никаких проблем.да! всех пугагет наверное политика ебай, пайпал и прочих. Дескать, чуть что - бабки нужно вернуть, или аккаунт заблокируют, бабки не отдадут и т д.
Ребята, реальными деньгами клиентов двигают финансовые институты, а не сайты. Все взаимоотношения между клиентами ведут эти сайты сами.
Если же клиент обратился в свой банк с заявлением(!!) о расследовании (фроде, обмане, кардерстве), банк не смог ответить своему клиенту сам, с согласия клиента инициировал разбирательство (диспут) в платежной системе, которое стоит от 100евро за обращение (обращений будет не одно, цены разные), ПС связалась с банком-эквайером, затянулась тягомотина , то тогдаааа.... и только тогдаааа!!!!...
Процедура примерно одинакова для всех процессингов мира.
С другой стороны, проигранные диспуты - это косяк (залет, процессинг обосрался, объяснительные , etc ...). Раз - банк простит. На второй - в угол поставит. На третий вышвырнет ваш шоп за дверь.
Извините за обширную писанину. Вырвалось. :)
JIRA. По деньгам не знаю. Пользуюсь на основной работе. ~9000 сотрудников. Нинарадаюсь после внедрения. Уверен, что есть и бюджетные предложения у них.
Если БД оооочень часто изменяется в момент бакапа. Если бакап глубокой ночью и БД в это время мало-активна - то пойдет.
Это опция mysqldump .
[root@host ~]# mysqldump --help | grep 'skip' | tail -n 3 --skip-opt Disable --opt. Disables --add-drop-table, --add-locks, (Defaults to on; use --skip-triggers to disable.) (Defaults to on; use --skip-tz-utc to disable.)[root@host ~]#
но поддержу коллегу выше и так же не советую. Вам тут весьма умные люди нашли время и посоветовали БЕСПЛАТНО как делать ПРАВИЛЬНО бакапы и строить для этого архитектуру, а не на коленке, лишь бы был дамп. Если у Вас есть время на проверки, изучения гипотез, задавания вопросов, пусть и глупых (лучше задать тупой вопрос, чем жалеть , что не задал) , я бы этим пользовался :) Не секрет, что "некоторые" менее чем за 100 у.е. - даже пальцы на клавиатуру не кладут :)
реплика не отстает ? все с этим ОК ? какая аппаратная архитектура сейчас ?
в тесте обязательно(!!!) попробуйте восстановится с реплики
да. с ручным приводом. слейв переводится в мастер.
он есть всегда. Но в любом случае связку мастер-слейв нужно мониторить, что бы не было такого , что слейв отвалился еще неделю назад, а мастер упал внезапно. Реплика отстала , данные не актуальны.
конечно может. Вопрос: "как падает мастер?"
Если это нечаянный drop database на мастере или delete from table , то эти изменения переедут на слейв тут же. Некорые СУБД позволяют сделать задержку. Например намеренно отставать от мастера на 10 минут.Если же на мастере внезапно упали диски, или еще как-то упал сервер то слейв поможет. В любом случае репликация не заменяет бакап, она повышает надежность от человеческого фактора и , так скажем, неприятных случайностей.
Опять же, никто не запрещает сделать вам два слейва.
работайте с мастером, дампите слейв. Ну или совсем по взрослому:
пишите в мастер, читайте со слейва (расходы на код. Если вы не программист, а код так не умеет - нанимаете программистов, которые напишут вам нужный код), дампите слейв. Сначала полный бакап, а потом инкрементальные.
скорее не медленнее, скажем так.
все современные реляционные SQL СУБД позволяют делать дамп без блокировки таблиц в большинстве случаев. Со своими неудобствами ... но тем не менее.
именно так. Пауза репликации, дамп, восстановление репликации, хотя онлайн тоже существует (без пауз), до этого вроде как percona и oracle додумались... но нужно подробнее почитать. Слейв догонит. Мастер имеет для этого запас в "буфере". Естественно между слейвом и мастером высокоскоростной линк, естественно - быстрые диски на обоих.
Так же существует масса инструментов инкрементального бакапа. Не нужно каждый раз бакапить всю сущность (БД или таблицу). Крупным данным не делают дамп. Есть xtrabackup и им подобные.
Возможно. Для этого существует планирование бакапов, планирование БД, своевременная очистка БД. Ежедневно работаю с БД , объемом 3.3Тбайт. Это система реального времени. Ею пользуются несколько миллионов человек круглосуточно по всему миру. Естественно есть специальная команда, отвечающая за бакап этой БД. Простой 10 минут - скандал. Простой час - скандал на всю страну. Уверяю, там нет баснословно дорогого оборудования, нано-технологий, блейд-серверов за килобаксы и тому подобного. Это каскад мастеров, слейвов, миддлов, надежных серверов надежного брэнда, архивных логов, точек отката. Никаких специализированных решений за бешеные деньги от вендора СУБД не используем (регулярно предлагают... но мы понимаем, что это "щеко-надувательство" и выполнение плана продаж). Работает 14 лет. Полет нормальный. Падает? - падает. Аварии бывают у всех. Но встает очень быстро.
Вставало бы несколько дней, если бы просто решили вкатить дамп :)
вопрос к ТСу. Чего больше ? Чтений или записей? БД конечно же мониторится и статистика ее поведения конечно же собирается за год, месяц, день, час ?
Призываю ТСа продумать бакап, четко для себя уяснить, что дамп - это плохо в его случае, когда он начинает класть БД критичного ресурса.
хоть кто-то поступает правильно :)---------- Добавлено 25.01.2018 в 00:10 ----------Как там , Константин? Рубль - талоны на питание. Деньги - все остальное ?:)
Вопрос к Вам - что делать с 54 000$ и 18 000Euro , находящимися на счетах в России?
