BiTel

Форум BiTel
bgbilling.ru     docs.bitel.ru     wiki.bitel.ru     dbinfo.bitel.ru     bgcrm.ru     billing.bitel.ru     bitel.ru    
Текущее время: 10 май 2024, 19:47

Часовой пояс: UTC + 5 часов [ Летнее время ]




Начать новую тему Ответить на тему  [ Сообщений: 47 ]  На страницу 1, 2  След.
Автор Сообщение
СообщениеДобавлено: 21 май 2010, 14:44 
Не в сети
Клиент
Аватара пользователя

Зарегистрирован: 20 апр 2009, 12:03
Сообщения: 3092
Откуда: Иркутск
Карма: 338
По логам и фактически договор переходит в статус "заблокирован", а в состоянии шлюза отображается:
"открыт". Стали разбираться - в таблице ipn_contract_status_{mid} дублируются записи для договоров:

Цитата:
mysql> select count(*) cnt, group_concat(status) from ipn_contract_status_9 group by cid having cnt>1;
+-----+----------------------+
| cnt | group_concat(status) |
+-----+----------------------+
| 2 | 0,0 |
| 2 | 0,0 |
| 2 | 0,0 |
| 2 | 0,0 |
| 2 | 0,0 |
| 2 | 0,0 |
| 2 | 0,0 |
| 2 | 0,0 |
| 2 | 0,0 |
| 2 | 0,0 |
| 2 | 0,0 |
| 2 | 0,0 |
| 2 | 0,0 |
| 2 | 0,0 |
| 2 | 0,0 |
| 2 | 0,0 |
| 2 | 0,0 |
| 2 | 0,0 |
| 2 | 0,0 |
| 2 | 0,0 |
| 2 | 0,0 |
| 2 | 0,0 |
| 2 | 0,0 |
| 2 | 0,0 |
| 2 | 0,0 |
| 2 | 0,0 |
| 2 | 0,0 |
| 2 | 0,0 |
| 2 | 0,0 |
| 2 | 0,0 |
| 2 | 0,0 |
| 2 | 0,0 |
| 2 | 0,0 |
| 2 | 0,0 |
| 2 | 0,0 |
| 2 | 0,0 |
| 2 | 0,0 |
| 2 | 0,0 |
| 2 | 0,0 |
| 2 | 0,0 |
| 2 | 0,0 |
| 2 | 0,0 |
| 2 | 0,0 |
| 2 | 0,0 |
| 2 | 0,0 |
| 2 | 0,2 |
| 2 | 0,0 |
| 2 | 0,0 |
| 2 | 0,0 |
| 2 | 0,0 |
| 2 | 0,0 |
| 2 | 0,0 |
| 2 | 0,0 |
| 2 | 0,0 |
| 2 | 0,0 |
| 2 | 0,0 |
| 2 | 0,0 |
+-----+----------------------+
57 rows in set (0.04 sec)


Цитата:
mysql> show create table ipn_contract_status_9;
+-----------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| Table | Create Table |
+-----------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| ipn_contract_status_9 | CREATE TABLE `ipn_contract_status_9` (
`cid` int(10) NOT NULL DEFAULT '0',
`status` tinyint(3) NOT NULL DEFAULT '0',
KEY `cid` (`cid`)
) ENGINE=InnoDB DEFAULT CHARSET=cp1251 |
+-----------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
1 row in set (0.00 sec)


ipn вер. 5.0 сборка 245 от 14.05.2010 18:37:08

Почему не сделать cid первичным ключом, а не просто индексом?


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: 24 май 2010, 19:04 
Не в сети
Разработчик

Зарегистрирован: 08 ноя 2007, 01:05
Сообщения: 8343
Откуда: Уфа
Карма: 238
вижу проблему ..Будем разбираться


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: 25 май 2010, 18:13 
Не в сети
Разработчик

Зарегистрирован: 08 ноя 2007, 01:05
Сообщения: 8343
Откуда: Уфа
Карма: 238
обновление выложено, в нем исправен код , чтобы такое не появилось и исправлен индекс
Код:
ALTER TABLE ipn_contract_status_$mid ADD PRIMARY KEY (`cid`), DROP INDEX `cid`;


Но это индекс не исправится пока данные в таблице неверные .. Для их восстановления могу предложить такой скрипт(желательно его запустить до обновления) :
Код:
drop table bgbilling.max_dates;
drop table bgbilling.problem_cids;
CREATE TABLE bgbilling.max_dates (
  `dt` DATETIME  NOT NULL,
  `cid` INT  NOT NULL,
  PRIMARY KEY (`cid`),
  INDEX `dt_idx`(`dt`)
);

CREATE TABLE bgbilling.problem_cids (
  `cid` INT  NOT NULL,
  PRIMARY KEY (`cid`)
);

INSERT INTO bgbilling.problem_cids
select cid from bgbilling.ipn_contract_status_1 group by cid having count(*) > 1;



INSERT INTO bgbilling.max_dates(dt, cid )
select max(dt), status.cid from  bgbilling.ipn_contract_status_1  as status
left join bgbilling.ipn_contract_status_log_1 as log ON status.cid = log.cid
where status.cid in (select cid from bgbilling.problem_cids)
group by status.cid ;

delete from bgbilling.ipn_contract_status_1
where
cid in
( select problem_cids.cid from bgbilling.problem_cids );

insert into bgbilling.ipn_contract_status_1( cid, status )
select distinct log.cid, log.action from bgbilling.ipn_contract_status_log_1 as log
left join bgbilling.max_dates on max_dates.dt = log.dt
where
log.cid in
( select problem_cids.cid from bgbilling.problem_cids )
and max_dates.dt is not null
order by log.cid ;

drop table bgbilling.max_dates;
drop table bgbilling.problem_cids;



Он восстанавливает статусы по последней строке в ipn_contract_status_log_1. 1-цу нужно везде заменить на код вашего модуля .


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: 25 май 2010, 18:21 
Не в сети
Разработчик

Зарегистрирован: 08 ноя 2007, 01:05
Сообщения: 8343
Откуда: Уфа
Карма: 238
я рекомендую всем , кто используют IPN проверить эту ситуацию. Т.к как минимум у троих она наблюдается точно


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: 26 май 2010, 06:33 
Не в сети
Клиент
Аватара пользователя

Зарегистрирован: 20 апр 2009, 12:03
Сообщения: 3092
Откуда: Иркутск
Карма: 338
Спасибо!


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: 27 май 2010, 18:52 
Не в сети

Зарегистрирован: 01 окт 2009, 13:19
Сообщения: 56
Карма: 0
Сегодня обновил модуль ipn до 5.0 сборка 251, при изменении в модули статуса шлюза, этот самый статус, не меняется, но запись в статистике об действии остается, и даже на шлюз приходит команда об изменении статуса. И теперь шедуллер переводит статус модуля в заблокирован(или открыт, смотря как оно отображается в модуле), но в Статистике состояния шлюза эта информация не отображается, как это было раньше. В свою очередь на шлюзе правило для договора изменяется.

Не очень понятно объяснил, поэтому приведу скриншет:


p.s. извиняюсь, не заметил скрипт, сейчас посмотрю что с этим можно сделать.

upd: да, помогло... надо бы это решение в обновление добавить.


Вложения:
bill_shed.jpg
bill_shed.jpg [ 203.72 КБ | Просмотров: 19676 ]
Вернуться к началу
 Профиль  
 
СообщениеДобавлено: 27 май 2010, 20:37 
Не в сети
Разработчик

Зарегистрирован: 08 ноя 2007, 01:05
Сообщения: 8343
Откуда: Уфа
Карма: 238
скрипт добавлен в обновление


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: 28 май 2010, 11:19 
Не в сети

Зарегистрирован: 17 фев 2009, 19:18
Сообщения: 437
Откуда: Коломна
Карма: 10
stark писал(а):
скрипт добавлен в обновление


А в какое обновление?
На сайте модуль IPN от 25 мая а RSS написано новость от 27 мая.

От 25 мая обновления стоят не работает.


Вложения:
Ver.JPG
Ver.JPG [ 63.59 КБ | Просмотров: 19655 ]
Вернуться к началу
 Профиль  
 
СообщениеДобавлено: 28 май 2010, 11:54 
Не в сети
Разработчик

Зарегистрирован: 08 ноя 2007, 01:05
Сообщения: 8343
Откуда: Уфа
Карма: 238
mazay-d писал(а):
stark писал(а):
скрипт добавлен в обновление


А в какое обновление?
На сайте модуль IPN от 25 мая а RSS написано новость от 27 мая.

От 25 мая обновления стоят не работает.


просто обновитесь ..ipn.. 252 билд для 5.0 и 4.6 от 27-го числа


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: 28 май 2010, 13:32 
Не в сети

Зарегистрирован: 01 окт 2009, 13:19
Сообщения: 56
Карма: 0
что-то тут не так, все равно у меня появляются дублирующие записи в bgbilling.ipn_contract_status_1... буду разбираться откуда и почему


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: 28 май 2010, 14:40 
Не в сети
Разработчик

Зарегистрирован: 08 ноя 2007, 01:05
Сообщения: 8343
Откуда: Уфа
Карма: 238
loginex писал(а):
что-то тут не так, все равно у меня появляются дублирующие записи в bgbilling.ipn_contract_status_1... буду разбираться откуда и почему

вы обновились до 252 билда ? при обновлении ошибок не было ?

какая версия ?

попробуйте сделать так

1. delete from sql_patches_history
2. скачайте ftp://bgbilling.ru/pub/bgbilling/5.0/ipn_5.0_252.zip
2. bg_installer.sh ipn_5.0_252.zip!

для 4.6 соответственно другую версию библиотеки скачайте


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: 28 май 2010, 14:44 
Не в сети

Зарегистрирован: 17 фев 2009, 19:18
Сообщения: 437
Откуда: Коломна
Карма: 10
Посмотрите, у вас на сайте ipn.. 252 билд для 4.6 от 25.05.10 17:42 числа, а не от 27 мая как вы пишите...


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: 28 май 2010, 14:48 
Не в сети

Зарегистрирован: 01 окт 2009, 13:19
Сообщения: 56
Карма: 0
stark писал(а):
loginex писал(а):
что-то тут не так, все равно у меня появляются дублирующие записи в bgbilling.ipn_contract_status_1... буду разбираться откуда и почему

вы обновились до 252 билда ? при обновлении ошибок не было ?

какая версия ?

попробуйте сделать так

1. delete from sql_patches_history
2. скачайте ftp://bgbilling.ru/pub/bgbilling/5.0/ipn_5.0_252.zip
2. bg_installer.sh ipn_5.0_252.zip!

для 4.6 соответственно другую версию библиотеки скачайте


обновился до 252 без ошибок вроде как.
нашел проблему - примари кей надо было изменить
вы в обновление добавили вот это :
ALTER TABLE ipn_contract_status_$mid ADD PRIMARY KEY (`cid`), DROP INDEX `cid`; ?


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: 28 май 2010, 14:59 
Не в сети
Разработчик

Зарегистрирован: 08 ноя 2007, 01:05
Сообщения: 8343
Откуда: Уфа
Карма: 238
loginex писал(а):

обновился до 252 без ошибок вроде как.
нашел проблему - примари кей надо было изменить
вы в обновление добавили вот это :
ALTER TABLE ipn_contract_status_$mid ADD PRIMARY KEY (`cid`), DROP INDEX `cid`; ?


да.. если открыть архив с модулем , то там есть файл init , в нем это есть сразу после запуска корректирующего скрипта


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: 09 июн 2010, 06:57 
Не в сети
Клиент
Аватара пользователя

Зарегистрирован: 20 апр 2009, 12:03
Сообщения: 3092
Откуда: Иркутск
Карма: 338
Сделал апдейт до 252 - не помогло:

Код:
mysql> show create table ipn_contract_status_9;
+-----------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| Table                 | Create Table                                                                                                                                                                        |
+-----------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| ipn_contract_status_9 | CREATE TABLE `ipn_contract_status_9` (
  `cid` int(10) NOT NULL DEFAULT '0',
  `status` tinyint(3) NOT NULL DEFAULT '0',
  KEY `cid` (`cid`)
) ENGINE=InnoDB DEFAULT CHARSET=cp1251 |
+-----------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
1 row in set (0.00 sec)


Кусок лога апдейта:
Код:
Found update for ipn build 245 packet ipn_5.0_252.zip updating to build 252
...
Module: ipn already installed.
Data extract finished...
Extract data => OK
Database updated...
Install ticket inserted..
Base update => OK
Reinit module instanses
REINIT module => 9
Unknown table 'max_dates'
Unknown table 'problem_cids'
Duplicate entry '179736' for key 'PRIMARY'
Module Instance init => OK
Executing call AddSchedulerTasks; param: ipn.sc
Scheduled class bitel.billing.server.ipn.LogCalculator already exists!
Scheduled class bitel.billing.server.ipn.IPNTestGates already exists!
Scheduled class bitel.billing.server.ipn.MaxCalculator already exists!
Result => true
Executing call PutFile; param: ipn.xml:actions
Result => true
Execute calls => OK
File's copy finished...
File copy => OK
Module ipn was successfull installed!
Please, restart BGBilling server.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: 09 июн 2010, 08:25 
Не в сети
Клиент
Аватара пользователя

Зарегистрирован: 20 апр 2009, 12:03
Сообщения: 3092
Откуда: Иркутск
Карма: 338
Пробуем выполнить все действия из init:
Код:
mysql> DROP TABLE max_dates;
ERROR 1051 (42S02): Unknown table 'max_dates'
mysql> DROP TABLE problem_cids;
ERROR 1051 (42S02): Unknown table 'problem_cids'
mysql> CREATE TABLE max_dates (
    ->   `dt` DATETIME  NOT NULL,
    ->   `cid` INT  NOT NULL,
    ->   PRIMARY KEY (`cid`),
    ->   INDEX `dt_idx`(`dt`)
    -> );
Query OK, 0 rows affected (0.07 sec)

mysql> CREATE TABLE problem_cids (
    ->   `cid` INT  NOT NULL,
    ->   PRIMARY KEY (`cid`)
    -> );
Query OK, 0 rows affected (0.06 sec)

mysql> INSERT INTO problem_cids
    -> SELECT cid FROM ipn_contract_status_9 group by cid having count(*) > 1;  Query OK, 266 rows affected (0.01 sec)
Records: 266  Duplicates: 0  Warnings: 0

mysql> INSERT INTO max_dates(dt, cid )
    -> SELECT max(dt), status.cid FROM  ipn_contract_status_9  as status
    -> LEFT JOIN ipn_contract_status_log_9 as log ON status.cid = log.cid
    -> WHERE status.cid in ( SELECT cid FROM problem_cids )
    -> GROUP BY status.cid ;
Query OK, 266 rows affected, 249 warnings (0.09 sec)
Records: 266  Duplicates: 0  Warnings: 249


Warnings: 249 - wtf?!
Смотрим, в чем проблема:
Код:
mysql> show warnings;
+---------+------+----------------------------+
| Level   | Code | Message                    |
+---------+------+----------------------------+
| Warning | 1048 | Column 'dt' cannot be null |
| Warning | 1048 | Column 'dt' cannot be null |
| Warning | 1048 | Column 'dt' cannot be null |
| Warning | 1048 | Column 'dt' cannot be null |
| Warning | 1048 | Column 'dt' cannot be null |
| Warning | 1048 | Column 'dt' cannot be null |
| Warning | 1048 | Column 'dt' cannot be null |
| Warning | 1048 | Column 'dt' cannot be null |
| Warning | 1048 | Column 'dt' cannot be null |
| Warning | 1048 | Column 'dt' cannot be null |
| Warning | 1048 | Column 'dt' cannot be null |
| Warning | 1048 | Column 'dt' cannot be null |
| Warning | 1048 | Column 'dt' cannot be null |
| Warning | 1048 | Column 'dt' cannot be null |
| Warning | 1048 | Column 'dt' cannot be null |
| Warning | 1048 | Column 'dt' cannot be null |
| Warning | 1048 | Column 'dt' cannot be null |
| Warning | 1048 | Column 'dt' cannot be null |
| Warning | 1048 | Column 'dt' cannot be null |
| Warning | 1048 | Column 'dt' cannot be null |
| Warning | 1048 | Column 'dt' cannot be null |
| Warning | 1048 | Column 'dt' cannot be null |
| Warning | 1048 | Column 'dt' cannot be null |
| Warning | 1048 | Column 'dt' cannot be null |
| Warning | 1048 | Column 'dt' cannot be null |
| Warning | 1048 | Column 'dt' cannot be null |
| Warning | 1048 | Column 'dt' cannot be null |
| Warning | 1048 | Column 'dt' cannot be null |
| Warning | 1048 | Column 'dt' cannot be null |
| Warning | 1048 | Column 'dt' cannot be null |
| Warning | 1048 | Column 'dt' cannot be null |
| Warning | 1048 | Column 'dt' cannot be null |
| Warning | 1048 | Column 'dt' cannot be null |
| Warning | 1048 | Column 'dt' cannot be null |
| Warning | 1048 | Column 'dt' cannot be null |
| Warning | 1048 | Column 'dt' cannot be null |
| Warning | 1048 | Column 'dt' cannot be null |
| Warning | 1048 | Column 'dt' cannot be null |
| Warning | 1048 | Column 'dt' cannot be null |
| Warning | 1048 | Column 'dt' cannot be null |
| Warning | 1048 | Column 'dt' cannot be null |
| Warning | 1048 | Column 'dt' cannot be null |
| Warning | 1048 | Column 'dt' cannot be null |
| Warning | 1048 | Column 'dt' cannot be null |
| Warning | 1048 | Column 'dt' cannot be null |
| Warning | 1048 | Column 'dt' cannot be null |
| Warning | 1048 | Column 'dt' cannot be null |
| Warning | 1048 | Column 'dt' cannot be null |
| Warning | 1048 | Column 'dt' cannot be null |
| Warning | 1048 | Column 'dt' cannot be null |
| Warning | 1048 | Column 'dt' cannot be null |
| Warning | 1048 | Column 'dt' cannot be null |
| Warning | 1048 | Column 'dt' cannot be null |
| Warning | 1048 | Column 'dt' cannot be null |
| Warning | 1048 | Column 'dt' cannot be null |
| Warning | 1048 | Column 'dt' cannot be null |
| Warning | 1048 | Column 'dt' cannot be null |
| Warning | 1048 | Column 'dt' cannot be null |
| Warning | 1048 | Column 'dt' cannot be null |
| Warning | 1048 | Column 'dt' cannot be null |
| Warning | 1048 | Column 'dt' cannot be null |
| Warning | 1048 | Column 'dt' cannot be null |
| Warning | 1048 | Column 'dt' cannot be null |
| Warning | 1048 | Column 'dt' cannot be null |
+---------+------+----------------------------+
64 rows in set (0.00 sec)

mysql> select * from max_dates;
+---------------------+--------+
| dt                  | cid    |
+---------------------+--------+
| 0000-00-00 00:00:00 | 116167 |
| 0000-00-00 00:00:00 | 116313 |
| 0000-00-00 00:00:00 | 116408 |
<...>
| 0000-00-00 00:00:00 | 182610 |
| 2009-12-07 11:34:03 | 165432 |
| 2010-02-24 09:24:17 | 179736 |
| 2010-06-03 11:40:07 | 182678 |
| 2010-06-03 11:40:07 | 182680 |
| 2010-06-08 09:00:03 | 176438 |
| 2010-06-08 10:59:17 | 172426 |
| 2010-06-08 10:59:23 | 178368 |
| 2010-06-08 11:28:05 | 181540 |
| 2010-06-08 11:40:05 | 182744 |
| 2010-06-08 11:40:05 | 182746 |
| 2010-06-09 02:28:07 | 181541 |
| 2010-06-09 02:28:08 | 181542 |
| 2010-06-09 02:28:09 | 181546 |
| 2010-06-09 09:10:03 | 151991 |
| 2010-06-09 09:16:54 | 143386 |
| 2010-06-09 09:51:27 | 181407 |
| 2010-06-09 09:59:17 | 181675 |
+---------------------+--------+
266 rows in set (0.00 sec)

Т.е. в ipn_contract_status_9 было много записей с dt = null, отчего в max_dates они попали с dt='0000-00-00 00:00:00'
Посмотрим, как это выглядит на примере конктретного договора:
Код:
mysql> SELECT * FROM  ipn_contract_status_9  as status LEFT JOIN ipn_contract_status_log_9 as log ON status.cid = log.cid WHERE status.cid =116167;
+--------+--------+------+------+--------+------+---------+
| cid    | status | dt   | cid  | action | uid  | comment |
+--------+--------+------+------+--------+------+---------+
| 116167 |      2 | NULL | NULL |   NULL | NULL | NULL    |
| 116167 |      0 | NULL | NULL |   NULL | NULL | NULL    |
+--------+--------+------+------+--------+------+---------+
2 rows in set (0.00 sec)

Это вообще клиент, у которого нет ни поинтов, ни модуля вл на договоре.

Ну ладно, посмотрим, что будет дальше.
А дальше нам нужно по-идее дропнуть все проблемные записи и вставить новые:
Цитата:
DELETE FROM ipn_contract_status_9
WHERE
cid in
( SELECT problem_cids.cid FROM problem_cids );

INSERT INTO ipn_contract_status_$mid( cid, status )
SELECT distinct log.cid, log.action FROM ipn_contract_status_log_9 as log
LEFT JOIN bgbilling.max_dates ON max_dates.dt = log.dt
WHERE
log.cid IN
( SELECT problem_cids.cid FROM problem_cids )
AND max_dates.dt is NOT NULL
ORDER BY log.cid ;


Не будем рубить с плеча - посмотрим, что должно вставиться:

Код:
mysql> SELECT distinct log.cid, log.action FROM ipn_contract_status_log_9 as log
    -> LEFT JOIN bgbilling.max_dates ON max_dates.dt = log.dt
    -> WHERE
    -> log.cid IN
    -> ( SELECT problem_cids.cid FROM problem_cids )
    -> AND max_dates.dt is NOT NULL
    -> ORDER BY log.cid;
+--------+--------+
| cid    | action |
+--------+--------+
| 143386 |      1 |
| 151991 |      1 |
| 165432 |      2 |
| 172426 |      2 |
| 172426 |      0 |
| 176438 |      0 |
| 178368 |      0 |
| 179736 |      0 |
| 181407 |      0 |
| 181540 |      0 |
| 181541 |      0 |
| 181542 |      0 |
| 181546 |      0 |
| 181675 |      0 |
| 182678 |      2 |
| 182680 |      2 |
| 182744 |      2 |
| 182746 |      2 |
+--------+--------+
18 rows in set (0.08 sec)


И видим, что вставляются далеко не все записи, да ещё с дубликатами. Поэтому индекс и не может добавиться в итоге.

Проблемы две (к разработчикам):

1) Почему-то большинство дубликатов соответствуют договорам, у которых нет записей в истории изменения статуса. При этом у всех таких договоров к тому же нет ни одного шлюза:
mysql> SELECT max(dt) dt, status.cid, gc.gid FROM ipn_contract_status_9 as status LEFT JOIN ipn_contract_status_log_9 as log ON status.cid = log.cid left join ipn_gate_contract_port_9 gc on status.cid=gc.cid WHERE status.cid in ( SELECT cid FROM problem_cids ) GROUP BY status.cid having dt is null and not gid is null;
Empty set (0.00 sec)

Откуда они берутся?

2) В запросе на вставку текущих статусов после удаления всех проблемных таблицы max_dates и ipn_contract_status_log_9 join-ятся только по дате, но не по cid, поэтому появляются дубликаты => не добавляется первичный ключ.

Поправленный запрос:
Цитата:
INSERT INTO ipn_contract_status_$mid( cid, status )
SELECT distinct log.cid, log.action FROM ipn_contract_status_log_9 as log
LEFT JOIN bgbilling.max_dates ON max_dates.dt = log.dt and max_dates.cid=log.cid
WHERE
log.cid IN
( SELECT problem_cids.cid FROM problem_cids )
AND max_dates.dt is NOT NULL
ORDER BY log.cid ;


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: 09 июн 2010, 08:31 
Не в сети
Клиент
Аватара пользователя

Зарегистрирован: 20 апр 2009, 12:03
Сообщения: 3092
Откуда: Иркутск
Карма: 338
Готово:

Код:
mysql> DROP TABLE max_dates;
Query OK, 0 rows affected (0.06 sec)

mysql> DROP TABLE problem_cids;
Query OK, 0 rows affected (0.04 sec)

mysql> CREATE TABLE max_dates (
    ->   `dt` DATETIME  NOT NULL,
    ->   `cid` INT  NOT NULL,
    ->   PRIMARY KEY (`cid`),
    ->   INDEX `dt_idx`(`dt`)
    -> );
Query OK, 0 rows affected (0.09 sec)

mysql> CREATE TABLE problem_cids (
    ->   `cid` INT  NOT NULL,
    ->   PRIMARY KEY (`cid`)
    -> );
Query OK, 0 rows affected (0.05 sec)

mysql> INSERT INTO problem_cids
    -> SELECT cid FROM ipn_contract_status_9 group by cid having count(*) > 1;
Query OK, 269 rows affected (0.02 sec)
Records: 269  Duplicates: 0  Warnings: 0

mysql> INSERT INTO max_dates(dt, cid )
    -> SELECT max(dt), status.cid FROM  ipn_contract_status_9  as status
    -> LEFT JOIN ipn_contract_status_log_9 as log ON status.cid = log.cid
    -> WHERE status.cid in ( SELECT cid FROM problem_cids )
    -> GROUP BY status.cid ;
Query OK, 269 rows affected, 252 warnings (0.04 sec)
Records: 269  Duplicates: 0  Warnings: 252

mysql> DELETE FROM ipn_contract_status_9
    -> WHERE
    -> cid in
    -> ( SELECT problem_cids.cid FROM problem_cids );
Query OK, 607 rows affected (0.05 sec)

mysql> INSERT INTO ipn_contract_status_9( cid, status )
    -> SELECT distinct log.cid, log.action FROM ipn_contract_status_log_9 as log
    -> LEFT JOIN bgbilling.max_dates ON max_dates.dt = log.dt and max_dates.cid = log.cid
    -> WHERE
    -> log.cid IN
    -> ( SELECT problem_cids.cid FROM problem_cids )
    -> AND max_dates.dt is NOT NULL
    -> ORDER BY log.cid ;
Query OK, 17 rows affected (0.01 sec)
Records: 17  Duplicates: 0  Warnings: 0

mysql> DROP TABLE max_dates;
Query OK, 0 rows affected (0.04 sec)

mysql> DROP TABLE problem_cids;
Query OK, 0 rows affected (0.04 sec)

mysql> ALTER TABLE ipn_contract_status_9 ADD PRIMARY KEY (`cid`), DROP INDEX `cid`;
Query OK, 0 rows affected (0.91 sec)
Records: 0  Duplicates: 0  Warnings: 0


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: 09 июн 2010, 18:35 
Не в сети
Разработчик

Зарегистрирован: 08 ноя 2007, 01:05
Сообщения: 8343
Откуда: Уфа
Карма: 238
Cromeshnic писал(а):
mysql> INSERT INTO max_dates(dt, cid )
-> SELECT max(dt), status.cid FROM ipn_contract_status_9 as status
-> LEFT JOIN ipn_contract_status_log_9 as log ON status.cid = log.cid
-> WHERE status.cid in ( SELECT cid FROM problem_cids )
-> GROUP BY status.cid ;
Query OK, 266 rows affected, 249 warnings (0.09 sec)
Records: 266 Duplicates: 0 Warnings: 249
[/code]

Warnings: 249 - wtf?!
Смотрим, в чем проблема:
Код:
mysql> show warnings;
+---------+------+----------------------------+
| Level   | Code | Message                    |
+---------+------+----------------------------+
| Warning | 1048 | Column 'dt' cannot be null |
| Warning | 1048 | Column 'dt' cannot be null |
| Warning | 1048 | Column 'dt' cannot be null |
| Warning | 1048 | Column 'dt' cannot be null |
| Warning | 1048 | Column 'dt' cannot be null |



это не критично , можно исправить во так :
Код:
INSERT INTO max_dates(dt, cid )
    -> SELECT max(dt), status.cid FROM  ipn_contract_status_9  as status
    -> LEFT JOIN ipn_contract_status_log_9 as log ON status.cid = log.cid
    -> WHERE status.cid in ( SELECT cid FROM problem_cids )  and log.dt is not null
    -> GROUP BY status.cid ;


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: 09 июн 2010, 18:47 
Не в сети
Разработчик

Зарегистрирован: 08 ноя 2007, 01:05
Сообщения: 8343
Откуда: Уфа
Карма: 238
Cromeshnic писал(а):
1) Почему-то большинство дубликатов соответствуют договорам, у которых нет записей в истории изменения статуса. При этом у всех таких договоров к тому же нет ни одного шлюза:
mysql> SELECT max(dt) dt, status.cid, gc.gid FROM ipn_contract_status_9 as status LEFT JOIN ipn_contract_status_log_9 as log ON status.cid = log.cid left join ipn_gate_contract_port_9 gc on status.cid=gc.cid WHERE status.cid in ( SELECT cid FROM problem_cids ) GROUP BY status.cid having dt is null and not gid is null;
Empty set (0.00 sec)

Откуда они берутся?


Вопрос интересный , явление носит системный характер. Т.е нет модуля ipn, но есть записи в ipn_contract_status_log и ipn_contract_status. Причину возникновения пока понять не могу . У этих договоров точно никогда не было модуля IPN?
Это можно испавить таким запросами
Код:
delete from  ipn_contract_status_$mid
where
cid not in (select cid from contract_module where mid = $mid );

delete from  ipn_contract_status_log_$mid
where
cid not in (select cid from contract_module where mid = $mid );


я добавил это в init 5.1. Для 5.0 и 4.6 не добавил..


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: 09 июн 2010, 18:49 
Не в сети
Разработчик

Зарегистрирован: 08 ноя 2007, 01:05
Сообщения: 8343
Откуда: Уфа
Карма: 238
Cromeshnic писал(а):
2) В запросе на вставку текущих статусов после удаления всех проблемных таблицы max_dates и ipn_contract_status_log_9 join-ятся только по дате, но не по cid, поэтому появляются дубликаты => не добавляется первичный ключ.

Поправленный запрос:
Цитата:
INSERT INTO ipn_contract_status_$mid( cid, status )
SELECT distinct log.cid, log.action FROM ipn_contract_status_log_9 as log
LEFT JOIN bgbilling.max_dates ON max_dates.dt = log.dt and max_dates.cid=log.cid
WHERE
log.cid IN
( SELECT problem_cids.cid FROM problem_cids )
AND max_dates.dt is NOT NULL
ORDER BY log.cid ;


согласен , ошибка . Исправил . Обновление выложено


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: 09 июн 2010, 18:51 
Не в сети
Разработчик

Зарегистрирован: 08 ноя 2007, 01:05
Сообщения: 8343
Откуда: Уфа
Карма: 238
теперь так :
Код:
DROP TABLE max_dates;
DROP TABLE problem_cids;
CREATE TABLE max_dates (
  `dt` DATETIME  NOT NULL,
  `cid` INT  NOT NULL,
  PRIMARY KEY (`cid`),
  INDEX `dt_idx`(`dt`)
);

CREATE TABLE problem_cids (
  `cid` INT  NOT NULL,
  PRIMARY KEY (`cid`)
);

INSERT INTO problem_cids
SELECT cid FROM ipn_contract_status_$mid group by cid having count(*) > 1;

INSERT INTO max_dates(dt, cid )
SELECT max(dt), status.cid FROM  ipn_contract_status_$mid  as status
LEFT JOIN ipn_contract_status_log_$mid as log ON status.cid = log.cid
WHERE status.cid in ( SELECT cid FROM problem_cids ) and log.dt is not null

GROUP BY status.cid ;

DELETE FROM ipn_contract_status_$mid
WHERE
cid in
( SELECT problem_cids.cid FROM problem_cids );

INSERT INTO ipn_contract_status_$mid( cid, status )
SELECT log.cid, log.action FROM ipn_contract_status_log_$mid as log
LEFT JOIN max_dates ON max_dates.dt = log.dt and max_dates.cid=log.cid
WHERE
log.cid IN
( SELECT problem_cids.cid FROM problem_cids )
AND max_dates.dt is NOT NULL
ORDER BY log.cid ;



DROP TABLE max_dates;
DROP TABLE problem_cids;


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: 06 июл 2010, 18:48 
Не в сети
Разработчик

Зарегистрирован: 08 ноя 2007, 01:05
Сообщения: 8343
Откуда: Уфа
Карма: 238
Cromeshnic писал(а):
Это вообще клиент, у которого нет ни поинтов, ни модуля вл на договоре.


По поводу этой проблемы вчера выложил обновление


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: 31 июл 2010, 18:21 
Не в сети

Зарегистрирован: 19 дек 2008, 17:46
Сообщения: 749
Карма: 10
В общем проблема так и осталась. Стоит версия 5,0 от 16,07,2010.
В базе запускаем ваш скрипт - глючные клиенты начинают нормально закрываться. Но вот клиенты у которых шлюз не трогали начинают глючить.
Запускаем опять ваш выше указанный скрипт и вуаяля опять проблема исчезает.
Получается чтобы решить проблему на всех клиентах, нужно передернуть у всех шлюз чтобы появилась проблема а затем запустить ваш скрипт.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: 03 авг 2010, 19:19 
Не в сети
Разработчик

Зарегистрирован: 08 ноя 2007, 01:05
Сообщения: 8343
Откуда: Уфа
Карма: 238
madmax писал(а):
В общем проблема так и осталась. Стоит версия 5,0 от 16,07,2010.
В базе запускаем ваш скрипт - глючные клиенты начинают нормально закрываться. Но вот клиенты у которых шлюз не трогали начинают глючить.
Запускаем опять ваш выше указанный скрипт и вуаяля опять проблема исчезает.
Получается чтобы решить проблему на всех клиентах, нужно передернуть у всех шлюз чтобы появилась проблема а затем запустить ваш скрипт.

доступ можете дать ?


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: 04 авг 2010, 11:47 
Не в сети
Клиент

Зарегистрирован: 02 дек 2009, 12:28
Сообщения: 93
Откуда: Ленинградская обл.
Карма: 5
Выяснил, что этот глюк происходит только после обновления.
Шлюзы с состоянием "заблокирован" на момент обновления остаются в этом состоянии. Скрипт, предложенный stark помогает.

Из состояния "заблокирован" не выходят только те договора, где отрицательный баланс. Если же баланс положительный или включен лимит, шлюз приходит в нормальное состояние после отработки шедъюлером "Проверки шлюзов IPN" (до этого момента ощущение, что ничего не сработало). Если не терпится, можно запустить скрипт еще раз, в клиенте нажать "обновить" и шлюз откроется.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: 04 авг 2010, 16:12 
Не в сети

Зарегистрирован: 19 дек 2008, 17:46
Сообщения: 749
Карма: 10
Да если бы было так как вы пишете, то не было бы проблем.
У нас наоборот клиенты работают, вот если его передернуть не закрывает шлюз, пока опять скрипт не перезапущу в mysql
По доступу попробуем дать, решим только как его в инет вывести


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: 04 авг 2010, 16:39 
Не в сети
Разработчик

Зарегистрирован: 08 ноя 2007, 01:05
Сообщения: 8343
Откуда: Уфа
Карма: 238
crez писал(а):
Выяснил, что этот глюк происходит только после обновления.
Шлюзы с состоянием "заблокирован" на момент обновления остаются в этом состоянии. Скрипт, предложенный stark помогает.

После каждого обновления такой глюк ?? т.е вы исправляете и снова появляется ? Елси так, то давайте доступ тоже

Этот же скрипт и запускается при обновлении. только там есть система кеширования, если он один раз запускался, то больше не запускается. Для чистоты эксперимента можно почистить кеш .
bg_installer.bat killhash m<MID>
где <MID> - это код модуля IPN .
И потом последнюю сборку ipn скачать с сайта и установить с ! в конце .


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: 04 авг 2010, 16:52 
Не в сети

Зарегистрирован: 19 дек 2008, 17:46
Сообщения: 749
Карма: 10
Ок проверим и сообщим результат


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: 04 авг 2010, 17:22 
Не в сети
Разработчик

Зарегистрирован: 08 ноя 2007, 01:05
Сообщения: 8343
Откуда: Уфа
Карма: 238
madmax писал(а):
Ок проверим и сообщим результат


желательно лог обновления тоже сохраните и покажите здесь


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: 05 авг 2010, 12:37 
Не в сети
Клиент

Зарегистрирован: 02 дек 2009, 12:28
Сообщения: 93
Откуда: Ленинградская обл.
Карма: 5
stark писал(а):
После каждого обновления такой глюк ?? т.е вы исправляете и снова появляется ? Елси так, то давайте доступ тоже

Этот же скрипт и запускается при обновлении. только там есть система кеширования, если он один раз запускался, то больше не запускается. Для чистоты эксперимента можно почистить кеш .
bg_installer.bat killhash m<MID>
где <MID> - это код модуля IPN .
И потом последнюю сборку ipn скачать с сайта и установить с ! в конце .


Почистил кэш, обновил все еще раз. Посмотрим сегодня на состояние шлюзов.
Доступ дать не проблема, поэтому в любой момент.


Вернуться к началу
 Профиль  
 
Показать сообщения за:  Поле сортировки  
Начать новую тему Ответить на тему  [ Сообщений: 47 ]  На страницу 1, 2  След.

Часовой пояс: UTC + 5 часов [ Летнее время ]


Кто сейчас на конференции

Сейчас этот форум просматривают: Google [Bot] и гости: 1


Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете добавлять вложения

Найти:
Перейти:  
cron
POWERED_BY
Русская поддержка phpBB
[ Time : 0.086s | 81 Queries | GZIP : On ]