Биллинговая система Nodeny

Главная категория => Курилка => Тема начата: Andrey Zentavr от 23 Июля 2010, 11:47:04



Название: NoDeny High Availability Service (NoDeny Кластер)
Отправлено: Andrey Zentavr от 23 Июля 2010, 11:47:04
Попросили меня обдумать возможность создания кластера для NoDeny.
Не пробовал ли кто-нибудь реализовать?

У меня пока две идеи на уме:
Идея 1: Виртуализация
Ставим два сервера, на обоих поднимаем что-то типа DRBD/Heartbeat (Линукс) + Xen. В Dom1 ставим Фрю. Примерно как я расписывал тут:
http://www.opennet.ru/base/net/xen_cluster_howto.txt.html - Создание кластера высокой доступности для XEN с Live миграцией в CentOS 5.3 с использованием VLAN и DRBD
+ http://www.opennet.ru/tips/2248_xen_freebsd_virtual.shtml
+ http://www.opennet.ru/tips/2369_xen_freebsd_virtual_guest_install.shtml

Минус тут я вижу один: если упадёт что-то внутри виртуальной машины - то система не работает.
Плюс: Если один из серверов мёртвый - второй подхватывает работу.

Идея 2: Два парралельных сервера
Ставим два сервера, поднимаем MySQL репликацию БД bill, ставим какой-нить carp (man 4 carp). Ставим набор Perl скриптов биллинга.

Минус: как быть со скриптом nomounth.pl? Не совсем хочется с людей два раза абонплату снимать.
Плюс: мне кажется с настройкой этого добра попроще чем в первом случае.


Название: Re: NoDeny High Availability Service (NoDeny Кластер)
Отправлено: VitalVas от 23 Июля 2010, 12:10:02
2-й вариант намного лутше чем 1-й

но есть ище 3-й вариант
ставиш 3 сервера
1-й основная бд
2-й реплецированая бд
3-й ядро биллинга

плюс: не гемороишся с кластерами и carp-ами и переходом на новый месяц
минус: сателиты работают только с 1-й бд


Название: Re: NoDeny High Availability Service (NoDeny Кластер)
Отправлено: stix от 23 Июля 2010, 12:19:18
зачем тебе чтото делать на второй БД?
они ж slave
просто в режиме выборки считай будет работать


Название: Re: NoDeny High Availability Service (NoDeny Кластер)
Отправлено: Andrey Zentavr от 23 Июля 2010, 14:05:04
2-й вариант намного лутше чем 1-й

но есть ище 3-й вариант
ставиш 3 сервера
1-й основная бд
2-й реплецированая бд
3-й ядро биллинга

плюс: не гемороишся с кластерами и carp-ами и переходом на новый месяц
минус: сателиты работают только с 1-й бд

Здесь узкое место - 3й сервер. Упал сервер - нету биллинга.
Дело в том, что сегодня ночью у нас что-то случилось с сервером биллинга - то ли электропитание прыгнуло, то ли УПС спортачил...  В общем имеем выгоревший блок питания, выгоревший слот на материнке и мёртвую сетевую. Сервер переставили. Но 4 часа даунтайма не хорошо сказалось на клиентах.

Я думаю третий предложенный Вами вариант не совсем надёжен.

ПыСы: А что по этому поводу думают авторы своего детища?


Название: Re: NoDeny High Availability Service (NoDeny Кластер)
Отправлено: VitalVas от 23 Июля 2010, 14:30:40
Здесь узкое место - 3й сервер. Упал сервер - нету биллинга.
Дело в том, что сегодня ночью у нас что-то случилось с сервером биллинга - то ли электропитание прыгнуло, то ли УПС спортачил...  В общем имеем выгоревший блок питания, выгоревший слот на материнке и мёртвую сетевую. Сервер переставили. Но 4 часа даунтайма не хорошо сказалось на клиентах.

Я думаю третий предложенный Вами вариант не совсем надёжен.
а ты подумай логически
упадет сервер с ядром: перестанет считатся трафик, отключаться некоторая логика, а инет будет в абонентов, т.к. сателит работает НАПРЯМУЮ с бд

самое узкое место в этой схеме - это основная бд
по этому и делается 2-а или больше сервера с бд, чтоб а аварийной ситуации можно было оперативно восстановить работу абонентов

что до питания - на 2-е фазы ставиш 2-е упс-ки и сервер с 2-а блоками питания(например Dell PowerEdge 2850)
 


Название: Re: NoDeny High Availability Service (NoDeny Кластер)
Отправлено: stix от 23 Июля 2010, 14:37:52
кластер правильней юзать


Название: Re: NoDeny High Availability Service (NoDeny Кластер)
Отправлено: blackjack от 23 Июля 2010, 15:46:43
Цитировать
упадет сервер с ядром: перестанет считатся трафик, отключаться некоторая логика, а инет будет в абонентов, т.к. сателит работает НАПРЯМУЮ с бд

бред


Название: Re: NoDeny High Availability Service (NoDeny Кластер)
Отправлено: Andrey Zentavr от 23 Июля 2010, 17:04:41
Здесь узкое место - 3й сервер. Упал сервер - нету биллинга.
Дело в том, что сегодня ночью у нас что-то случилось с сервером биллинга - то ли электропитание прыгнуло, то ли УПС спортачил...  В общем имеем выгоревший блок питания, выгоревший слот на материнке и мёртвую сетевую. Сервер переставили. Но 4 часа даунтайма не хорошо сказалось на клиентах.

Я думаю третий предложенный Вами вариант не совсем надёжен.
а ты подумай логически
упадет сервер с ядром: перестанет считатся трафик, отключаться некоторая логика, а инет будет в абонентов, т.к. сателит работает НАПРЯМУЮ с бд

самое узкое место в этой схеме - это основная бд
по этому и делается 2-а или больше сервера с бд, чтоб а аварийной ситуации можно было оперативно восстановить работу абонентов

что до питания - на 2-е фазы ставиш 2-е упс-ки и сервер с 2-а блоками питания(например Dell PowerEdge 2850)
 

У меня ещё почти половина абонентов юзает авторизатор.
Я так понимаю, что если ядро биллинга упало, то агент авторизации/PPPoE-сервер спокойно в базу бросит запрос, что абонент авторизирован, а модуль фаерволла в течении некоторого времени (вроде 45 секунд) откроет интернет. Но пока ядро мёртвое - снятие средств/подсчёт трафика не работает. Верно?


Название: Re: NoDeny High Availability Service (NoDeny Кластер)
Отправлено: versus от 23 Июля 2010, 17:07:26
Слишком перемудрили ))

Вариант с виртуализацией это гемор, если хочется потрахатся тогда конечно, только причем там дрпд и хертбет непонятно, это вчерашний день. Миграция машин внутри виртуальной инфрастукрутры должна происходить свободно, но это так отвлеченно в облако ))

Вам минимум надо 2 машины, на которые заливаем мускул (мастер- мастер или мастер - слейв в зависимости от нагрузки ) и нодени. Поднимаем хертбит на фре (/usr/ports/sysutils/heartbeat) или карп, как захочете. В обеих машинках прописывает скрипты в кроне. Только на одной переход на новый месяц  откланяем минут на 10-15 позже чем на первой. Скрипт перехода построен таким образом что не будет повторно снимать абонплату с тех с кого снял.
При падении одного сервера, мы автоматом переключаем ип на второй , который на себя берет основную нагрузку, так как мускулы у нас синхронизированы, то соотвественно файрволы будут включены ровно в таком же виде какой был на первом сервере.
Минусом будет разрыв сессий у пользователй. Но я думаю они переживут.


Название: Re: NoDeny High Availability Service (NoDeny Кластер)
Отправлено: Andrey Zentavr от 24 Июля 2010, 01:34:25
Вариант с виртуализацией это гемор, если хочется потрахатся тогда конечно, только причем там дрпд и хертбет непонятно, это вчерашний день. Миграция машин внутри виртуальной инфрастукрутры должна происходить свободно, но это так отвлеченно в облако ))
Можно использовать какую-нибудь кластерную ФС. Пример выше был "из собственного опыта". Поднималось всё для одного завода в запорожье. ..на Линухах.

Вам минимум надо 2 машины, на которые заливаем мускул (мастер- мастер или мастер - слейв в зависимости от нагрузки ) и нодени. Поднимаем хертбит на фре (/usr/ports/sysutils/heartbeat) или карп, как захочете. В обеих машинках прописывает скрипты в кроне. Только на одной переход на новый месяц  откланяем минут на 10-15 позже чем на первой. Скрипт перехода построен таким образом что не будет повторно снимать абонплату с тех с кого снял.
При падении одного сервера, мы автоматом переключаем ип на второй , который на себя берет основную нагрузку, так как мускулы у нас синхронизированы, то соотвественно файрволы будут включены ровно в таком же виде какой был на первом сервере.
Минусом будет разрыв сессий у пользователй. Но я думаю они переживут.
То есть, грубо говоря, на одном сервере ставим снятие первого числа, на втором - второго. При втором запуске скрипт nomounth.pl увидит что уже за, предположим, август месяц абонка была снята вчера (почему переспрашиваю - потому что не сильно хочется в полночь каждого первого числа судорожно отрубать из крона второй скрипт) и ничего снимать не будет.

...Если я правильно рассуждаю, то, в принципе, MySQL Multi-Master replication + carp(4) = profit?


Название: Re: NoDeny High Availability Service (NoDeny Кластер)
Отправлено: versus от 24 Июля 2010, 11:26:05
Крон перехода ставим не второго а именно первого числа но не в полночь а в пол первого ночи. Иначе потребуется включать переход с ключиком в строке.

Кластерная фс вам не нужна, данные файловой системы на нодени не меняются. Скрипты не меняются, поэтому даже рсинк излишен. А БД реплицируется между системами через свои каналы. Ессно репликация мастер мастер предпочтительнее, в виду того что падение системы может произойти в тот момент когда вы спите Конечно  смотреть на нагрузку надо 

 


Название: Re: NoDeny High Availability Service (NoDeny Кластер)
Отправлено: blackjack от 23 Декабря 2010, 13:21:59
не подскажете чем чревато 2 запущеных ядра на разных серверах которые работают с отдельными базами в режиме мастер-мастер?


Название: Re: NoDeny High Availability Service (NoDeny Кластер)
Отправлено: versus от 24 Декабря 2010, 22:47:31
сначало хотелось бы понять зачем вам два ядра


Название: Re: NoDeny High Availability Service (NoDeny Кластер)
Отправлено: Rico-X от 19 Января 2011, 21:40:39
Тема актуальна. Нашел готовую реализацию решения для другого биллинга http://xlabz.org/archives/303
Там в теме дан интересный скрипт который проверяет в каком состоянии находится сервер в данный момент (Основной или резервный) и в зависимости от этого запускает или останавливает ядро биллинга. Если кто заинтересован, может помочь и переделать данный скрипт под NODENY?


Название: Re: NoDeny High Availability Service (NoDeny Кластер)
Отправлено: Sork от 16 Марта 2011, 20:15:39
остался непонятен момент - будут ли авторизоваться пользователи на сателлите, который подключен к Slave-БД при мертвом ядре биллинга?

Можно было бы тогда разместить биллинг в Датацентре, на каждый сателлит реплицировать БД даже на разных площадках и не иметь проблем при проблемах доступа к основной БД (переключаться на Slave).


Название: Re: NoDeny High Availability Service (NoDeny Кластер)
Отправлено: versus от 18 Марта 2011, 02:22:56
Ядро биллинга ка кбы не учавствует в процессе авторизации, оно только дает команду на выключение.

Авторизация идет двумя способами, классический через ключик, посредством сервера авторизации и
новый рекомендуемый через радиус.
Основная проблема при авторизации на слейв базе будет в том. что сервер доступа noserver.pl  не увидет авторизованных клиентов и соотвественно не пустит их в интернет.
Поэтому как бы лучше все таки делать репликацию мастер мастер, что бы авторизация распространялась на всех участников репликации, с которой у же сервер доступа сможет выпустить клиента в интернет.


Название: Re: NoDeny High Availability Service (NoDeny Кластер)
Отправлено: blackjack от 18 Марта 2011, 19:25:07
при репликации мастер мастер, постоянно вылазят косяки с дупликейт записями, вследствие хранимых процедур и триггеров


Название: Re: NoDeny High Availability Service (NoDeny Кластер)
Отправлено: Rico-X от 18 Марта 2011, 20:13:13
Есть такое дело и carp падает переодически. По этому использую мастер-слейф, если что можно руками за пару минут переключить и не париться.


Название: Re: NoDeny High Availability Service (NoDeny Кластер)
Отправлено: Efendy от 19 Марта 2011, 00:21:50
при репликации мастер мастер, постоянно вылазят косяки с дупликейт записями, вследствие хранимых процедур и триггеров
процитируй ошибку какую-нить


Название: Re: NoDeny High Availability Service (NoDeny Кластер)
Отправлено: Andrey Zentavr от 19 Марта 2011, 01:31:08
при репликации мастер мастер, постоянно вылазят косяки с дупликейт записями, вследствие хранимых процедур и триггеров
Можно конфиг обоих MySQL серваков?

может поможет такой финт:
ServerA:
Код:
### Rackspace MySQL 4.1/5.0 Verbose Configuration File v1.1
###
### This is a base configuration file containing the most frequently used
### settings with reasonably defined default values for configuring and
### tuning MySQL. Note that these settings can likely be further tuned
### in order to get optimum performance from MySQL based upon the database
### configuration and hardware platform.
###
### While the settings provided are likely sufficient for most situations, an
### exhaustive list of settings (with descriptions) can be found at:
###
### For MySQL 4.1:
### http://dev.mysql.com/doc/refman/4.1/en/server-system-variables.html
### For MySQL 5.0:
### http://dev.mysql.com/doc/refman/5.0/en/server-system-variables.html
###
### Further configuration file examples (with and without comments) can be
### found in @@@mysql_server_docdir@@@.
###
### Take care to only add/remove/change a setting if you are comfortable
### doing so! For Rackspace customers, if you have any questions or concerns,
### please contact the MySQL Database Services Team. Be aware that some work
### performed by this team can involve additional billable fees.

[mysqld]

# __________________
#< General Settings >
# ------------------
#        \   ^__^
#         \  (oo)\_______
#            (__)\       )\/\
#                ||----w |
#                ||     ||

# Misc Settings
# -------------
datadir=/var/lib/mysql
#tmpdir=/var/lib/mysqltmp
socket=/var/lib/mysql/mysql.sock
skip-locking
#skip-name-resolve
table_cache=2048
thread_cache_size=16
back_log=100
max_connect_errors=10000
open-files-limit=20000
interactive_timeout=600
wait_timeout=600
#max_connections=200

# Set this to change the way MySQL handles validation, data
# conversion, etc. Be careful with this setting as it can
# cause unexpected results and horribly break some applications!
# Note, too, that it can be set per-session and can be hard set
# in stored procedures.
#sql_mode=TRADITIONAL

# Slow Query Log Settings
# -----------------------
#log-slow-queries=/var/lib/mysqllogs/slow-log
#long_query_time=2
#log-queries-not-using-indexes

# Global, Non Engine-Specific Buffers
# -----------------------------------
max_allowed_packet=16M
tmp_table_size=64M
max_heap_table_size=64M

# Generally, it is unwise to set the query cache to be
# larger than 64-128M as this can decrease performance
# since the penalty for flushing the cache can become
# significant.
query_cache_size=32M

# Per-Thread Buffers
# ------------------
sort_buffer_size=1M
read_buffer_size=1M
read_rnd_buffer_size=8M
join_buffer_size=1M

# __________________________
#< Engine Specific Settings >
# --------------------------
#        \   ^__^
#         \  (oo)\_______
#            (__)\       )\/\
#                ||----w |
#                ||     ||

# Set this to force MySQL to use a particular engine / table-type
# for new tables. This setting can still be overridden by specifying
# the engine explicitly in the CREATE TABLE statement.
#default-storage-engine=InnoDB

# MyISAM
# ------

# Not sure what to set this to?
# Try running a 'du -sch /var/lib/mysql/*/*.MYI'
# This will give you a good estiamte on the size of all the MyISAM indexes.
# (The buffer may not need to set that high, however)
key_buffer_size=64M

# This setting controls the size of the buffer that is allocated when
# sorting MyISAM indexes during a REPAIR TABLE or when creating indexes
# with CREATE INDEX or ALTER TABLE.
myisam_sort_buffer_size=64M

# InnoDB
# ------
# Note: While most settings in MySQL can be set at run-time, InnoDB
# variables require restarting MySQL to apply.

# If the customer already has InnoDB tables and wants to change the
# size of the InnoDB tablespace and InnoDB logs, then:
# 1. Run a full backup with mysqldump
# 2. Stop MySQL
# 3. Move current ibdata and ib_logfiles out of /var/lib/mysql
# 4. Uncomment the below innodb_data_file_path and innodb_log_file_size
# 5. Start MySQL (it will recreate new InnoDB files)
# 6. Restore data from backup
#innodb_data_file_path=ibdata1:2000M;ibdata2:10M:autoextend
#innodb_log_file_size=100M

# InnoDB loves RAM. For customers using mostly InnoDB, consider setting
# this variable somewhat liberally. Do make sure the server is 64-bit,
# however, if you plan on setting it above 1.5-2GB.
innodb_buffer_pool_size=16M

#innodb_additional_mem_pool_size=20M

# innodb_file_per_table can be useful in certain cases
# but be aware that it does not scale well with a
# large number of tables!
#innodb_file_per_table=1

# Somewhat equivalent to table_cache for InnoDB
# when using innodb_file_per_table.
#innodb_open_files=1024

# If you are not sure what to set this two, the
# following formula can offer up a rough idea:
# (number of cpus * number of disks * 2)
#innodb_thread_concurrency=16

# _____________________________
#< Replication/Backup Settings >
# -----------------------------
#        \   ^__^
#         \  (oo)\_______
#            (__)\       )\/\
#                ||----w |
#                ||     ||

server-id=2

# Master Side
master-host=10.0.0.1
master-user=replication
master-password=Sf8kClPs
master-port=3306

replicate-same-server-id=0

# It may be wise to include the server-name or an easy identifier
# to the server in these logs, such as 'log-bin=/var/lib/mysqllogs/db1-bin-log'
log-bin=/var/lib/mysqllogs/bin-log
log-bin-index=/var/lib/mysqllogs/bin-log.index
relay-log=/var/lib/mysqllogs/relay-log
relay-log-index=/var/lib/mysqllogs/relay-log.index

# MySQL 5.0+ Only
expire_logs_days=14

# This is usually only needed when setting up chained replication.
log-slave-updates

# Enable this to make replication more resilient against server
# crashes and restarts, but can cause higher I/O on the server.
#sync_binlog=1

# If the server is a standard MySQL slave, it would be wise
# to enable read-only mode to prevent stray writes that could
# break replication
# read_only=1

# MySQL 5.0+ Only
# Uncomment the following when enabling multi-master replication
# Do NOT uncomment these unless you know exactly what you are doing!
auto_increment_increment=10
auto_increment_offset=2

## databases
replicate-do-db = nodeny
replicate-do-db = repdb
replicate-ignore-db=mysql
replicate-ignore-db=test

# _________________
#< Script Settings >
# -----------------
#        \   ^__^
#         \  (oo)\_______
#            (__)\       )\/\
#                ||----w |
#                ||     ||
# (You probably do not need to change these)

[mysql.server]
user=mysql
#basedir=/var/lib

[mysqld_safe]
log-error=/var/log/mysqld.log
pid-file=/var/run/mysqld/mysqld.pid
open-files-limit=65535

ServerB:
Код:
### Rackspace MySQL 4.1/5.0 Verbose Configuration File v1.1
###
### This is a base configuration file containing the most frequently used
### settings with reasonably defined default values for configuring and
### tuning MySQL. Note that these settings can likely be further tuned
### in order to get optimum performance from MySQL based upon the database
### configuration and hardware platform.
###
### While the settings provided are likely sufficient for most situations, an
### exhaustive list of settings (with descriptions) can be found at:
###
### For MySQL 4.1:
### http://dev.mysql.com/doc/refman/4.1/en/server-system-variables.html
### For MySQL 5.0:
### http://dev.mysql.com/doc/refman/5.0/en/server-system-variables.html
###
### Further configuration file examples (with and without comments) can be
### found in @@@mysql_server_docdir@@@.
###
### Take care to only add/remove/change a setting if you are comfortable
### doing so! For Rackspace customers, if you have any questions or concerns,
### please contact the MySQL Database Services Team. Be aware that some work
### performed by this team can involve additional billable fees.

[mysqld]

# __________________
#< General Settings >
# ------------------
#        \   ^__^
#         \  (oo)\_______
#            (__)\       )\/\
#                ||----w |
#                ||     ||

# Misc Settings
# -------------
datadir=/var/lib/mysql
#tmpdir=/var/lib/mysqltmp
socket=/var/lib/mysql/mysql.sock
skip-locking
#skip-name-resolve
table_cache=2048
thread_cache_size=16
back_log=100
max_connect_errors=10000
open-files-limit=20000
interactive_timeout=600
wait_timeout=600
#max_connections=200

# Set this to change the way MySQL handles validation, data
# conversion, etc. Be careful with this setting as it can
# cause unexpected results and horribly break some applications!
# Note, too, that it can be set per-session and can be hard set
# in stored procedures.
#sql_mode=TRADITIONAL

# Slow Query Log Settings
# -----------------------
#log-slow-queries=/var/lib/mysqllogs/slow-log
#long_query_time=2
#log-queries-not-using-indexes

# Global, Non Engine-Specific Buffers
# -----------------------------------
max_allowed_packet=16M
tmp_table_size=64M
max_heap_table_size=64M

# Generally, it is unwise to set the query cache to be
# larger than 64-128M as this can decrease performance
# since the penalty for flushing the cache can become
# significant.
query_cache_size=32M

# Per-Thread Buffers
# ------------------
sort_buffer_size=1M
read_buffer_size=1M
read_rnd_buffer_size=8M
join_buffer_size=1M

# __________________________
#< Engine Specific Settings >
# --------------------------
#        \   ^__^
#         \  (oo)\_______
#            (__)\       )\/\
#                ||----w |
#                ||     ||

# Set this to force MySQL to use a particular engine / table-type
# for new tables. This setting can still be overridden by specifying
# the engine explicitly in the CREATE TABLE statement.
#default-storage-engine=InnoDB

# MyISAM
# ------

# Not sure what to set this to?
# Try running a 'du -sch /var/lib/mysql/*/*.MYI'
# This will give you a good estiamte on the size of all the MyISAM indexes.
# (The buffer may not need to set that high, however)
key_buffer_size=64M

# This setting controls the size of the buffer that is allocated when
# sorting MyISAM indexes during a REPAIR TABLE or when creating indexes
# with CREATE INDEX or ALTER TABLE.
myisam_sort_buffer_size=64M

# InnoDB
# ------
# Note: While most settings in MySQL can be set at run-time, InnoDB
# variables require restarting MySQL to apply.

# If the customer already has InnoDB tables and wants to change the
# size of the InnoDB tablespace and InnoDB logs, then:
# 1. Run a full backup with mysqldump
# 2. Stop MySQL
# 3. Move current ibdata and ib_logfiles out of /var/lib/mysql
# 4. Uncomment the below innodb_data_file_path and innodb_log_file_size
# 5. Start MySQL (it will recreate new InnoDB files)
# 6. Restore data from backup
#innodb_data_file_path=ibdata1:2000M;ibdata2:10M:autoextend
#innodb_log_file_size=100M

# InnoDB loves RAM. For customers using mostly InnoDB, consider setting
# this variable somewhat liberally. Do make sure the server is 64-bit,
# however, if you plan on setting it above 1.5-2GB.
innodb_buffer_pool_size=16M

#innodb_additional_mem_pool_size=20M

# innodb_file_per_table can be useful in certain cases
# but be aware that it does not scale well with a
# large number of tables!
#innodb_file_per_table=1

# Somewhat equivalent to table_cache for InnoDB
# when using innodb_file_per_table.
#innodb_open_files=1024

# If you are not sure what to set this two, the
# following formula can offer up a rough idea:
# (number of cpus * number of disks * 2)
#innodb_thread_concurrency=16

# _____________________________
#< Replication/Backup Settings >
# -----------------------------
#        \   ^__^
#         \  (oo)\_______
#            (__)\       )\/\
#                ||----w |
#                ||     ||

server-id=1

# Master Side
master-host=10.0.0.2
master-user=replication
master-password=4wi3k78J
master-port=3306

replicate-same-server-id=0

# It may be wise to include the server-name or an easy identifier
# to the server in these logs, such as 'log-bin=/var/lib/mysqllogs/db1-bin-log'
log-bin=/var/lib/mysqllogs/bin-log
log-bin-index=/var/lib/mysqllogs/bin-log.index
relay-log=/var/lib/mysqllogs/relay-log
relay-log-index=/var/lib/mysqllogs/relay-log.index

# MySQL 5.0+ Only
expire_logs_days=14

# This is usually only needed when setting up chained replication.
log-slave-updates

# Enable this to make replication more resilient against server
# crashes and restarts, but can cause higher I/O on the server.
#sync_binlog=1

# If the server is a standard MySQL slave, it would be wise
# to enable read-only mode to prevent stray writes that could
# break replication
# read_only=1

# MySQL 5.0+ Only
# Uncomment the following when enabling multi-master replication
# Do NOT uncomment these unless you know exactly what you are doing!
auto_increment_increment=10
auto_increment_offset=1

## databases
replicate-do-db = nodeny
replicate-do-db = repdb
replicate-ignore-db=mysql
replicate-ignore-db=test


# _________________
#< Script Settings >
# -----------------
#        \   ^__^
#         \  (oo)\_______
#            (__)\       )\/\
#                ||----w |
#                ||     ||
# (You probably do not need to change these)

[mysql.server]
user=mysql
#basedir=/var/lib

[mysqld_safe]
log-error=/var/log/mysqld.log
pid-file=/var/run/mysqld/mysqld.pid
open-files-limit=65535

Именно вся прелесть в настройках для автоинкремента:
на одной ноде
Код:
auto_increment_increment=10
auto_increment_offset=1

и второй ноде
Код:
auto_increment_increment=10
auto_increment_offset=2


Название: Re: NoDeny High Availability Service (NoDeny Кластер)
Отправлено: versus от 20 Марта 2011, 12:54:57
Четные айди на одном мастере,  нечетные на другом при добалвении записей никто не отменял!!!


Название: Re: NoDeny High Availability Service (NoDeny Кластер)
Отправлено: Rico-X от 20 Марта 2011, 14:56:27
При такой настройке вылазит бок при генерации карт оплаты, так что инкременты приходится вернуть на исходные.


Название: Re: NoDeny High Availability Service (NoDeny Кластер)
Отправлено: Andrey Zentavr от 21 Марта 2011, 01:00:16
Четные айди на одном мастере,  нечетные на другом при добалвении записей никто не отменял!!!

Ну как бы именно про это и пост


Название: Re: NoDeny High Availability Service (NoDeny Кластер)
Отправлено: Andrey Zentavr от 21 Марта 2011, 01:01:50
При такой настройке вылазит бок при генерации карт оплаты, так что инкременты приходится вернуть на исходные.
Какой собственно бок вылазит?? Я понимаю тот, когда простыня карт в настройках биллинга отображается? :D
Да, есть такое.. Я когда с UTM5 переносил карточки - намучался с этим.


Название: Re: NoDeny High Availability Service (NoDeny Кластер)
Отправлено: Rico-X от 25 Марта 2011, 15:46:33
Бок в том, что то сгенерит одну карту и вылетет с ошибкой, то кинет целую простыню, то нагенерит кучу карт с одним номером, уже не помню всех вариаций с пол года назад было, потом плюнул и сделал мастер-слейф репликацию+ ежедневный бэкап как мастера так и слейва, благо падение базы не такое частое событие, чтоб нельзя было руками переткнуть. Ну и простенький скрипт на баше набросал, который у меня меняет мастер и слейф местами, так что хоть с мобильника его запускай, юзал 1 раз (выгорел бп на мастере) время простоя менее 10 минут, не особо критично при том что сателиты продолжали работать и уже авторизировавшиеся пользователи связи не потеряли.


Название: Re: NoDeny High Availability Service (NoDeny Кластер)
Отправлено: Demeo от 18 Ноября 2011, 20:43:42
Как раз сейчас есть необходимость в распределении нагрузки на 2 сервера с фейловером. CARP, я так понял, самый простой вариант. Если не юзать карт, еще какие-нибудь траблы могут быть при мастер-мастер репликации? Может кто поделится своим рабочим вариантом?

Юзаем pppoe авторизацию - два сервера не будут помехой? И какой тогда интерфейс писать в конфиге mpd - локальный или carp?

А если объединить в carp внешние интерфейсы - проблемы будут? Или лучше взять еще один IP? Но тогда будут отваливаться всякие там авторизации по IP


Название: Re: NoDeny High Availability Service (NoDeny Кластер)
Отправлено: Rico-X от 19 Ноября 2011, 17:01:44
Иногда происходит разсинхронизация баз данных. Может стоит просто вынести отдельно pppoe авторизаторы оставив базу на отдельном сервере? Сателитов можно наплодить сколько угодно для снятия нагрузки. Carp иногда сбоит и самопроизвольно отваливается, с чем связано не выявил. Система мастер-мастер поработала в тестовом режиме пару месяцев, но так как случались сбои в работе перевел на мастер-слейф, что в разы стабильней, а вместо carp использовал банальный алиас, который при необходимости применялся на "живом" сервере отдельным скриптом привязанным к мониторингу.


Название: Re: NoDeny High Availability Service (NoDeny Кластер)
Отправлено: Demeo от 20 Ноября 2011, 00:28:39
Скриптом, к сожалению, не получится распределить нагрузку на рррое-сервера. А CARP дает как бы рапределение+фейловер


Название: Re: NoDeny High Availability Service (NoDeny Кластер)
Отправлено: Rico-X от 20 Ноября 2011, 10:30:03
А можно мне открыть страшную тайну ЗАЧЕМ распределять нагрузку на pppoe сервера какими-то левыми средствами если несколько pppoe серверов запущенных в одной сети сами "из коробки" распределяют нагрузку между собой. Какой первый ответил, тот и подцепил пользователь, первым отвечает менее нагруженный, что не так?


Название: Re: NoDeny High Availability Service (NoDeny Кластер)
Отправлено: Андрій от 20 Ноября 2011, 11:41:01
А можно мне открыть страшную тайну ЗАЧЕМ распределять нагрузку на pppoe сервера какими-то левыми средствами если несколько pppoe серверов запущенных в одной сети сами "из коробки" распределяют нагрузку между собой. Какой первый ответил, тот и подцепил пользователь, первым отвечает менее нагруженный, что не так?

в такому варіанті є шанс що під одним логіном підключаться два користувача на різні сателіти


Название: Re: NoDeny High Availability Service (NoDeny Кластер)
Отправлено: 0xbad0c0d3 от 20 Ноября 2011, 11:51:59
в такому варіанті є шанс що під одним логіном підключаться два користувача на різні сателіти
Да ладно! Не верю! ))


Название: Re: NoDeny High Availability Service (NoDeny Кластер)
Отправлено: Андрій от 20 Ноября 2011, 12:00:22
в такому варіанті є шанс що під одним логіном підключаться два користувача на різні сателіти
Да ладно! Не верю! ))

недавно тестував - якщо кілька разів позапускати підключення то підключиться з тим самим логіном на інший сателіт, може підкажете як зробити щоб такого не було ?


Название: Re: NoDeny High Availability Service (NoDeny Кластер)
Отправлено: 0xbad0c0d3 от 20 Ноября 2011, 14:04:57
Я даже не знаю, что и сказать. Из коробки все было как нужно...
Гадать что уже менялось (хотя более чем уверен, что ответ будет: "ничего не менялось!") как-то не в кайф...
самый простой способ это переделать radcheck


Название: Re: NoDeny High Availability Service (NoDeny Кластер)
Отправлено: Андрій от 20 Ноября 2011, 15:17:56
Я даже не знаю, что и сказать. Из коробки все было как нужно...
Гадать что уже менялось (хотя более чем уверен, что ответ будет: "ничего не менялось!") как-то не в кайф...
самый простой способ это переделать radcheck

хм, буду ще раз перевіряти, але radcheck справді був стандартний. Ще питання коли користувач вже підключений то radtest має проходити чи ні ? бо в мене він завжди проходить не в залежносі чи активна сесія чи ні


Название: Re: NoDeny High Availability Service (NoDeny Кластер)
Отправлено: Rico-X от 21 Ноября 2011, 09:59:14
в такому варіанті є шанс що під одним логіном підключаться два користувача на різні сателіти
Как это у них так получается? Ну если ничего не меняли и реально такой баг, что мешает на сатерит 1 завести виланы 2->N а на сателит 2 виланы N+1->M. Хотя как уже говорилось смотрите на radcheck


Название: Re: NoDeny High Availability Service (NoDeny Кластер)
Отправлено: 0xbad0c0d3 от 21 Ноября 2011, 11:12:55
Да не, на самом деле радчек тут не при делах (по дефолту). Его просто можно примостырить чтобы проходила такая проверка.


Название: Re: NoDeny High Availability Service (NoDeny Кластер)
Отправлено: Андрій от 21 Ноября 2011, 11:21:11
Да не, на самом деле радчек тут не при делах (по дефолту). Его просто можно примостырить чтобы проходила такая проверка.

а як переробити radcheck, щоб була перевірка чи підключений користувач чи ні ?  Пробував, щоб перевіряло по таблиці dblogin, але як виявилось вона кожних 7 сек. очищається і в цей час інший користувач може підключитися з тим самим логіном і паролем


Название: Re: NoDeny High Availability Service (NoDeny Кластер)
Отправлено: 0xbad0c0d3 от 21 Ноября 2011, 14:54:14
добавить в запрос, который в radcheck:
Код:
and auth = 'no'


Название: Re: NoDeny High Availability Service (NoDeny Кластер)
Отправлено: Андрій от 21 Ноября 2011, 14:58:19
добавить в запрос, который в radcheck:
Код:
and auth = 'no'

дякую!


Название: Re: NoDeny High Availability Service (NoDeny Кластер)
Отправлено: Андрій от 21 Ноября 2011, 15:37:02
добавить в запрос, который в radcheck:
Код:
and auth = 'no'

підключення все одно відбувається, могли б ви повністю написати процедуру, можливо я десь зробив помилку


Название: Re: NoDeny High Availability Service (NoDeny Кластер)
Отправлено: Андрій от 21 Ноября 2011, 15:39:37
після того як я підключаюсь\відключаюсь з іншого сателіту ключик на кілька секунд пропадає а потім знову появляється


Название: Re: NoDeny High Availability Service (NoDeny Кластер)
Отправлено: Андрій от 21 Ноября 2011, 18:44:46
розібрався, все працює.


Название: Re: NoDeny High Availability Service (NoDeny Кластер)
Отправлено: Rico-X от 22 Ноября 2011, 09:59:40
Выложи решение на память.


Название: Re: NoDeny High Availability Service (NoDeny Кластер)
Отправлено: Андрій от 22 Ноября 2011, 10:30:27
Код:
DROP PROCEDURE IF EXISTS `radcheck`;
DELIMITER $$ 
CREATE PROCEDURE `radcheck` (IN login VARCHAR(64))
BEGIN
  SELECT id,name,'Password' AS Attribute,AES_DECRYPT(passwd,'hardpass3') AS Value,'=='
    FROM users WHERE name=login and auth = 'no';
END$$
DELIMITER ;