По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
Перенос или миграция базы данных MySQL или MariaDB между серверами обычно занимает всего несколько простых шагов. В этой статье мы расскажем про них, и вы сможете легко перенести данные со старого Linux сервера на новый, импортировать и выполнить проверку того что все прошло без ошибок. Поехали!
Подготовка
Первым делом нужно убедиться, что и на старом, и на новом сервере установлена одинаковая версия MySQL с одинаковым дистрибутивом. Для этого в командной строке выполните:
mysql -V
После этого нужно убедиться, что на новом сервере хватает места для файла дампа старой базы и импортированной базы данных (например, используя команду df).
Экспортируем базу данных MySQL в файл дампа
Внимание! Не переносите каталог data на новый сервер и не меняйте внутреннюю структуру БД.
Сначала на старом сервере остановите службу mysql или mariadb, используя команду systemctl:
# systemctl stop mariadb
ИЛИ
# systemctl stop mysql
Затем сделайте дамп ваших баз MySQL с помощью команды mysqldump:
# mysqldump -u
[user] -p --all-databases > all_databases.sql
Если база одна, то можно использовать команду:
# mysqldump -u root -p --opt [database name] > database_name.sql
Перенос дампа MySQL на новый сервер
Теперь используйте команду scp, чтобы перенести файл дампа на новый сервер. После подключения база будет перенесена на новый сервер.
# scp all_databases.sql user@merionet.ru:~/ [Все базы]
# scp database_name.sql user@merionet.ru:~/ [Одна база]
Импорт файла дампа MySQL на новый сервер
После того как файл дампа был перенесен, нужно выполнить следующую команду для импорта всех баз данных в MySQL.
# mysql -u [user] -p --all-databases < all_databases.sql [All Databases]
# mysql -u [user] -p newdatabase < database_name.sql [Singe Database]
Проверка импорта
После завершения импорта вы можете проверить базы данных на обоих серверах:
# mysql -u user -p
# show databases;
Перенос баз данных и пользователей MySQL на новый сервер
Если нужно переместить все свои БД MySQL, пользователей, разрешения и структуру данных старого сервера на новый, то нужно использовать команду rsync. С ее помощью скопируется весь контент из каталога данных mysql или mariadb на новый сервер.
# rsync -avz /var/lib/mysql/* user@merionet.ru:/var/lib/mysql/
Как только передача завершится, вы можете установить владельца каталога данных mysql или mariadb для пользователя и группы mysql. Для того чтобы убедиться, что что все файлы были переданы можно выполнить просмотр каталога.
# chown mysql:mysql -R /var/lib/mysql/
# ls -l /var/lib/mysql/
Готово! Мы только что очень быстро и просто выполнили миграцию всех баз со старого сервера на новый.
В данной статье будет описан процесс настройки вашей АТС Asterisk с провайдером Zadarma.
Настройка с помощью файлов конфигурации Asterisk
Важный момент - у вас уже должны быть логин и пароль для данного провайдера, получить которые можно на сайте. Для примера будут указаны следующие данные: 1234567 - ваш SIP - номер, полученный при регистрации, ****** - ваш пароль и 321 - номер экстеншена. Рассмотрим самый стандартный вариант, при котором исходящие звонки с вышеуказанного внутреннего номера (экстеншена) маршрутизируются через SIP - транк zadarma-trunk.
Для начала настройки необходимо отредактировать файл sip.conf следующим образом:
[general]
srvlookup=yes
[zadarma-trunk]
host=sip.zadarma.com
insecure=invite,port
type=friend
fromdomain=sip.zadarma.com
disallow=allallow=alaw&ulaw
dtmfmode=autosecret=password
defaultuser=1234567
trunkname=zadarma-trunk
fromuser=1234567
callbackextension=zadarma-trunk
context=zadarma-in
qualify=400
directmedia=no
[321]
secret=password
host=dynamic
type=friend
context=zadarma-out
Настройки маршрутизации производятся в файле extensions.conf следующим образом:
[zadarma-in]
exten => 1234567,1, Dial(SIP/321)
[zadarma-out]
exten => _XXX,1,Dial(SIP/${EXTEN})
exten => _XXX.,1,Dial(SIP/${EXTEN}@zadarma-trunk)
Для контекста [zadarma-in] все входящие вызовы направляются на экстеншен 321, и для [zadarma-out] возможны два варианта: если в набираемом номере 3 цифры, то вызов пойдет на один из экстеншенов, настроенных на вашей АТС, если же 4 и больше - вызов уйдет на транк zadarma-trunk.
В случае, если ваша АТС находится не за маршрутизатором, а имеет публичный IP-адрес, то входящие вызовы можно принимать по следующей схеме, с использованием SIP URI.
К примеру, 12039485767 - ваш DID номер подключенный к Zadarma, а 200.132.13.43 - адрес вашего Asterisk. Для этого нужно в личном кабинете в поле Настройки-Прямой телефонный номер нужно указать маршрутизацию с прямого DID номера на внешний сервер (SIP URI) в формате 12039485767@200.132.13.43 и отредактировать sip.conf следующим образом:
[zadarma]
host=sipde.zadarma.com
type=friend
insecure=port,invite
context=zadarma-in
disallow=all
allow=alaw&ulaw
dtmfmode = auto
directmedia=no
[zadarma2]
host=siplv.zadarma.com
type=friend
insecure=port,invite
context=zadarma-in
disallow=all
allow=alaw&ulaw
dtmfmode = auto
directmedia=no
[zadarma3]
host=sipfr.zadarma.com
type=friend
insecure=port,invite
context=zadarma-in
disallow=all
allow=alaw&ulaw
dtmfmode = auto
directmedia=no
Указываем исходящий маршрут в файле extensions.conf
[zadarma-in]
extended => 12039485767,1,Dial(SIP/321)
Далее будет рассмотрена настройка транка для FreePBX 13 версии.
Настройка с помощью FreePBX
Важный момент, перед настройкой транка необходимо включить функцию SRV Lookup. Для этого необходимо пройти по пути Settings → Asterisk SIP Settings → Chan SIP Settings и для опции Enable SRV Lookup выбрать опцию Yes.
Далее происходит уже знакомый процесс настройки транка – переходим во вкладку Connectivity → Trunks. Необходимо нажать на кнопку + Add Trunk и добавить chan_sip транк
Присваиваем имя транку – в данном случае это «Zadarma_test»
Далее необходимо перейти во вкладку sip Settings и указать настройки для входящей и исходящей связи (вкладки Outgoing и Incoming)
Для удобства копирования, приведу настройки SIP - транка и строки регистрации в текстовом виде:
host=sip.zadarma.com
insecure=invite,port
type=friend
fromdomain=sip.zadarma.com
disallow=all
allow=alaw&ulaw
dtmfmode=auto
secret=******
defaultuser=1234567
fromuser=1234567
qualify=400
directmedia=no
1234567:******@sip.zadarma.com/1234567
Далее нужно нажать на Submit и Apply Config. Переходим к настройке входящего маршрута
Маршрутизация
Во вкладке Connectivity → Inbound Routes по уже знакомому способу создаём входящий маршрут (кнопка + Add Inbound Route), присваиваем описание и указываем номер.
Далее нажимаем Submit и переходим к настройке исходящего маршрута: переходим по пути Connectivity → Outbound Route, создаём новый исходящий маршрут таким же образом как и входящий и указываем следующие параметры – имя маршрута, CID маршрута и используемый транк (тот, что был настроен в начале всего процесса.)
Последним шагом является настройка Dial Patterns – переходим в одноименную вкладку и после поля префикс необходимо поставить одну единственную точку – иначе не будет возможности совершать исходящие вызовы.
После этого необходимо нажать Submit и Apply Config. На этом настройка заканчивается.
Когда синхронизация менее важна, чем фактическая доставка, трафиком часто можно управлять с помощью метода взвешенной справедливой организации очереди на основе классов (CBWFQ). В CBWFQ участвующие классы трафика обслуживаются в соответствии с назначенной им политикой. Например, трафику, помеченному как AF41, может быть гарантирована минимальная пропускная способность. Для трафика, помеченного как AF21, также может быть гарантирована минимальная пропускная способность, возможно, меньшая, чем объем, предоставленный трафику AF41. Немаркированный трафик может получить любую оставшуюся полосу пропускания.
CBWFQ имеет понятие справедливости, когда различные классы трафика могут доставляться по перегруженному каналу. CBWFQ обеспечивает справедливое обслуживание пакетов в очереди в соответствии с политикой QoS. Пакеты будут отправляться всем классам трафика с назначенной им полосой пропускания.
Например, предположим, что пропускная способность канала составляет 1024 Кбит / с. Для класса трафика AF41 гарантирован минимум 256 Кбит / с. Для класса AF31 гарантирована скорость минимум 128 Кбит / с. Для класса AF21 гарантирована скорость минимум 128 Кбит / с. Это дает нам соотношение 2: 1: 1 между этими тремя классами. Остальные 512 Кбит / с не распределены, то есть доступны для использования другим трафиком. Включая нераспределенную сумму, полное соотношение составляет 256: 128: 128: 512, что сокращается до 2: 1: 1: 4.
Чтобы решить, какой пакет будет отправлен следующим, очередь обслуживается в соответствии с политикой CBWFQ. В этом примере пропускная способность 1024 Кбит / с делится на четыре части с соотношением 2: 1: 1: 4. Для простоты предположим, что перегруженный интерфейс будет обслуживать пакеты в очереди за восемь тактов:
Тактовый цикл 1. Будет отправлен пакет AF41.
Тактовый цикл 2. Будет отправлен еще один пакет AF41.
Тактовый цикл 3. Будет отправлен пакет AF31.
Тактовый цикл 4. Будет отправлен пакет AF21.
Тактовые циклы 5-8. Пакеты с другими классификациями, а также неклассифицированные пакеты будут отправлены.
В этом примере предполагается, что есть пакеты, представляющие каждый из четырех классов, находящихся в буфере, поставленных в очередь для отправки. Однако не всегда все бывает так однозначно. Что происходит, когда нет пакетов из определенного класса трафика для отправки, даже если есть место в гарантированном выделении минимальной полосы пропускания?
Гарантированная минимальная пропускная способность не является резервированием. Если класс трафика, которому назначен гарантированный минимум, не требует полного распределения, другие классы трафика могут использовать полосу пропускания. Также нет жестких ограничений гарантированного минимума пропускной способности. Если объем трафика для определенного класса превышает гарантированный минимум и полоса пропускания доступна, трафик для класса будет проходить с большей скоростью. Таким образом, происходящее могло бы выглядеть примерно так:
Тактовый цикл 1. Отправляется пакет AF41.
Тактовый цикл 2. Нет пакета AF41 для отправки, поэтому вместо него отправляется пакет AF31.
Тактовый цикл 3. Отправлен еще один пакет AF31.
Тактовый цикл 4. Нет пакета AF21 для отправки, поэтому отправляется неклассифицированный пакет.
Тактовые циклы 5-7. Отправляются пакеты с другими классификациями, а также неклассифицированные пакеты.
Тактовый цикл 8. Нет более классифицированных или неклассифицированных пакетов для отправки, поэтому отправляется еще один пакет AF31.
В результате неиспользованная полоса пропускания делится между классами с избыточным трафиком.
Перегрузка
CBWFQ не увеличивает пропускную способность перегруженного канала. Скорее, алгоритм предусматривает тщательно контролируемое совместное использование перенапряженного канала, отражающее относительную важность различных классов трафика. В результате совместного использования CBWFQ трафик доставляется через перегруженный канал, но с меньшей скоростью по сравнению с тем же каналом в незагруженное время.
Невозможно переоценить различие между "совместным использованием перегруженного канала" и "созданием полосы пропускания из ничего". Распространенное заблуждение о QoS заключается в том, что, несмотря на точки перегрузки на сетевом пути, взаимодействие с пользователем останется идентичным. Это совсем не так. Инструменты QoS, такие как CBWFQ, по большей части предназначены для того, чтобы максимально использовать плохую ситуацию. При выборе того, когда и когда пересылать трафик, QoS также выбирает, какой трафик отбрасывать. Среди потоков, передаваемых по сети, есть "победители" и "проигравшие".
LLQ является заметным исключением, поскольку предполагается, что трафик, обслуживаемый LLQ, настолько критичен, что он будет обслуживаться, исключая другой трафик, вплоть до назначенного ограничения полосы пропускания. LLQ стремится сохранить пользовательский опыт.
Другие инструменты управления перегрузкой QoS
Формирование трафика - это способ изящно ограничить классы трафика определенной скоростью. Например, трафик, помеченный как AF21, может иметь скорость 512 Кбит / с. Формирование изящное. Он допускает номинальные всплески выше определенного предела перед отбрасыванием пакетов. Это позволяет TCP более легко настраиваться на требуемую скорость. Когда пропускная способность сформированного класса трафика отображается на графике, результат показывает нарастание до предельной скорости, а затем постоянную скорость передачи на протяжении всего потока. Формирование трафика чаще всего применяется к классам трафика, заполненным слоновьими потоками.
Слоновидные потоки - это долговечные потоки трафика, используемые для максимально быстрого перемещения больших объемов данных между двумя конечными точками. Слоновые потоки могут заполнять узкие места в сети собственным трафиком, подавляя меньшие потоки. Распространенная стратегия QoS состоит в том, чтобы формировать скорость трафика слоновьих потоков, чтобы в узком месте оставалась достаточная пропускная способность для эффективного обслуживания других классов трафика.
Применение политик аналогично формированию трафика, но более жестко обращается с избыточным (несоответствующим) трафиком. Вместо того, чтобы допускать небольшой всплеск выше определенного предела пропускной способности, как при формировании перед сбросом, применение политик немедленно отбрасывает избыточный трафик. При столкновении с ограничителем трафика затронутый трафик увеличивается до предела пропускной способности, превышает его и отбрасывается. Такое поведение отбрасывания заставляет TCP заново запускать процесс наращивания мощности. Полученный график выглядит как пилообразный. Применение политик может использоваться для выполнения других задач, таких как перемаркировка несоответствующего трафика на значение DSCP с более низким приоритетом, а не отбрасывание.