Перейти до

Объединение баз данных двух биллингов Ubilling


Рекомендованные сообщения

Естественно, ip сети и города - разные, версии Ubilling - одинаковые.
Собственно, как это сделать максимально просто и безопасно?
 
То, до чего сам додумался - это использовать "Модуль Миграция 2"
Для это планирую сделать экспорт нужных полей из базы данных с помощью запроса


 

SELECT
  users.login, users.password, # login;password;
  users.ip, nethosts.mac, # IP;MAC;
  users.tariff, users.cash, users.Credit, users.CreditExpire, # tariff;cash;credit limit;credit expire date;
  city.cityname, # city;
  street.streetname, # street;
  build.buildnum, # build;
  apt.entrance, apt.floor, apt.apt, # entrance;floor;apt;
  phones.phone, phones.mobile, # phone;mobile;
  emails.email, # email;
  userreg.address, # address;
  realname.realname, # realname;
  contracts.contract, # contract;
  users.AlwaysOnline, users.Down, users.Passive  # AlwaysOnline state;Down state;Passive state
FROM
  city, street, build, apt, address, users, nethosts, phones, emails, userreg, realname, contracts
WHERE
  build.streetid = street.id AND
  apt.buildid = build.id AND
  address.aptid = apt.id AND
  address.login = users.login AND
  nethosts.ip = users.IP AND
  userreg.login=users.login AND
  realname.login = users.login AND
  phones.login=users.login AND
  emails.login = users.login AND
  userreg.login = users.login AND
  contracts.login = users.login
INTO OUTFILE '/tmp/ubilling.exp'
FIELDS TERMINATED BY ';'
ENCLOSED BY ''
LINES TERMINATED BY '\n'

 


По sql запросу вопрос прежде всего к уважаемому nightfly : оттуда ли (таблицы, поля) я беру значения?

Відредаговано mac
Ссылка на сообщение
Поделиться на других сайтах

с такими вопросами....

ручками всё перенесите, вы ж наебнете себе всё без понимания что вы и куда суете

 

имена табличек похожи на правду, пробуйте на виртуалках, сдампите себе БД с первого и пробуйте перенести данные со второго

попутно проверяя всё ли в БД занеслось как надо и не ахуел ли старгейзер от таких манипуляций

Відредаговано l1ght
Ссылка на сообщение
Поделиться на других сайтах

Да, конечно на виртуалке испытаю сначала.

Просто глубоко не копал, что и где лежит.

Имена полей и таблиц - вроде как адекватны назначению.

Но могут же быть, типа, legacy, и не использоваться в новых версиях убилинга

В частности, смущает таблица users (оч много столбцов)

Ссылка на сообщение
Поделиться на других сайтах

Да, конечно на виртуалке испытаю сначала.

Просто глубоко не копал, что и где лежит.

Имена полей и таблиц - вроде как адекватны назначению.

Но могут же быть, типа, legacy, и не использоваться в новых версиях убилинга

В частности, смущает таблица users (оч много столбцов)

users это то с чем работает старгейзер

 

почитайте FAQ, посмотрите видео в вики есть ссылочки

думаю станет понятнее, а вообще неиспользуемых табличек у нас нет

все важны и все нужны, стартовая позиция собрать все логины и IP из таблички users

это то по чему есть связь по всем остальным таблицам

соотвественно бабло (cash), кредит, имя тарифа, всё остальное живет в других табличках

Ссылка на сообщение
Поделиться на других сайтах

Уже есть готовый SQL запрос выборки всех необходимых данных. Сейчас немного подкорректирую под миграцию 2 и вперед, если Вы желаете так переносить. А вообще вариантов масса.

Ссылка на сообщение
Поделиться на других сайтах

Уже есть готовый SQL запрос выборки всех необходимых данных. Сейчас немного подкорректирую под миграцию 2 и вперед, если Вы желаете так переносить. А вообще вариантов масса.

 

Ну что-то типа такого:

            SELECT 
                    `users`.`login`, `ip`, `mac`, `Tariff`,  `Cash`,  `Credit`, `CreditExpire`, 
                    `cityname`, `streetname`, `buildnum`, `entrance`, `floor`, `apt`,
                    `phones`.`phone`, `mobile`, `emails`.`email`, 
                    concat(`cityname`, ' ', `streetname`, ' ', `buildnum`, IF(`apt`, concat('/',`apt`), '')) AS `fulladress`,
                    `realname`.`realname`, `contract`, `AlwaysOnline`, `Down`, `Passive`                   
            FROM `users` LEFT JOIN `nethosts` USING (`ip`)
                    LEFT JOIN `realname` ON (`users`.`login`=`realname`.`login`)
                    LEFT JOIN `address` ON (`users`.`login`=`address`.`login`)
                    LEFT JOIN `apt` ON (`address`.`aptid`=`apt`.`id`)
                    LEFT JOIN `build` ON (`apt`.`buildid`=`build`.`id`)
                    LEFT JOIN `street` ON (`build`.`streetid`=`street`.`id`)
                    LEFT JOIN `city` ON (`street`.`cityid`=`city`.`id`)
                    LEFT JOIN `phones` ON (`users`.`login`=`phones`.`login`)
                    LEFT JOIN `contracts` ON (`users`.`login`=`contracts`.`login`)
                    LEFT JOIN `emails` ON (`users`.`login`=`emails`.`login`)
Ссылка на сообщение
Поделиться на других сайтах
Опубліковано: (відредаговано)

l1ght, Pautiina, большое спасибо за советы и решения!

Pautiina, в вашем запросе в

`users`.`login`, `ip`,

пропущен `password`. Правильнее будет

`users`.`login`, `password`, `ip`,
Відредаговано mac
Ссылка на сообщение
Поделиться на других сайтах

Там еще данные по платежам, начислениям АП, нетхосты и куча потрохов других есть. Если логины юзеров, сети, и прочее такое не перекрываются, то в принципе, можно пробовать переносить данные в лоб. Проблема будет, только с адресами из "город-улица-дом", так как там куча связей по id, и хорошо бы писать для этого какой-то "заселятор" на пхп. Ненавижу такие штуки.

Ссылка на сообщение
Поделиться на других сайтах

Ничего (логины юзеров, сети, и прочее такое) не перекрывается.

Т.к. сначала данные были в одном биллинге, потом их разделили на 2 (ломать - не строить).

Дальше они жили своей жизнью. И теперь из-за автоматизации платежей (opayz) их нужно объединить.

Nightfly, Ваше мнение понял, заселятор я не осилю, поэтому - или миграция, или вручную.

Ссылка на сообщение
Поделиться на других сайтах

 

 

Nightfly, Ваше мнение понял, заселятор я не осилю, поэтому - или миграция, или вручную.

Ну по идее, какая-то из миграций должна пытаться угадывать, чего там делать с адресами. Точно не уверен - отродясь ими не пользовался. Кстати экспорт в ЦСВ-шку вроде был в "мастере отчетов".

Остальное да, можно переносить в лоб, тупо табличками.

Ссылка на сообщение
Поделиться на других сайтах

 

l1ght, Pautiina, большое спасибо за советы и решения!

Pautiina, в вашем запросе в

`users`.`login`, `ip`,

пропущен `password`. Правильнее будет

`users`.`login`, `password`, `ip`,

Пусть будет так :)

Ссылка на сообщение
Поделиться на других сайтах

Появились новые вопросы по "Миграции 2"

1. Когда создавать недостающие тарифы - до или после миграции?

2. В wiki есть рекомендация выключить stargazer перед миграцией. Но тогда перестает работать ubilling. Это как раз тот случай, когда нужно использовать опцию NOSTGCHECKPID ?

Ссылка на сообщение
Поделиться на других сайтах
  • 1 year later...

Всім привіт.

З*єдную два убілла.
Мігрігую по вікі "Міграція 2" але щось не прьот. Де косячу підскажіть. Послідовність така: 1. Роблю вибірку з бази і зберігаю в csv. Добавляю в новий білл руцями місто, мережі, дхцп, НАС, тарифи. Далі csv в "міграцію 2". БАчу "First of imported data rows" з данними, далі "Select data columns and their values" в таргеті міняю мережу і тицяю кнопу. Бачу таблоід з юзерами де все гут. Тушу СТГ і тицю "Єс процесс регістрації юзерів". Далі бачу "DEBUG" з усіма юзерами що мігрують і в кінці php скипт. Копіпасс в php консоль і запускаю. Далі цей же скріпт кольоровий і в "Console debug data" порожньо.

Старт СТГ. Заходжу в онлайн а там нема ніхто, з нових мається на увазі.

Відредаговано sirko.n
Ссылка на сообщение
Поделиться на других сайтах

При спробі на "бойовому" сервері  видало щось новеньке
 

Fatal error: Uncaught Error: Call to undefined function mysql_num_rows() in /usr/local/www/apache24/data/billing/modules/general/sqlconsole/index.php(220) : eval()'d code:16 Stack trace: #0 /usr/local/www/apache24/data/billing/modules/general/sqlconsole/index.php(220): eval() #1 /usr/local/www/apache24/data/billing/index.php(67): include_once('/usr/local/www/...') #2 {main} thrown in /usr/local/www/apache24/data/billing/modules/general/sqlconsole/index.php(220) : eval()'d code on line 16

Перепровірив. Вставляв код в консоль php.

Відредаговано sirko.n
Ссылка на сообщение
Поделиться на других сайтах
2 часа назад, sirko.n сказал:

При спробі на "бойовому" сервері  видало щось новеньке
 


Fatal error: Uncaught Error: Call to undefined function mysql_num_rows() in /usr/local/www/apache24/data/billing/modules/general/sqlconsole/index.php(220) : eval()'d code:16 Stack trace: #0 /usr/local/www/apache24/data/billing/modules/general/sqlconsole/index.php(220): eval() #1 /usr/local/www/apache24/data/billing/index.php(67): include_once('/usr/local/www/...') #2 {main} thrown in /usr/local/www/apache24/data/billing/modules/general/sqlconsole/index.php(220) : eval()'d code on line 16

Перепровірив. Вставляв код в консоль php.

несовместимость старых версий пхп с новыми

надо код адаптировать под новые реалии mysqli_*

Ссылка на сообщение
Поделиться на других сайтах
14 минут назад, sirko.n сказал:

З php кодом в мене не дуже (( 

Якісь варіки крім "руками" ще можливі? 

Відсипати кілограм грошей, тим в кого зі всім "дуже".

Ссылка на сообщение
Поделиться на других сайтах
  • 1 month later...

Тоже пришлось выгрузить юзеров из убиллинга в другой биллинг (продали оператора).

получилось что то типа такого

SELECT 
users.login as Login, contracts.contract as Номер_Договора, realname.realname as ФИO,
concat(city.cityname,' ',street.streetname,' ',build.buildnum,'/',apt.apt,' подъезд ',apt.entrance,' этаж ',apt.floor) 
as Адрес_подключения,users.tariff as Тариф,phones.phone as Телефон,phones.mobile as Мобилный,passportdata.birthdate
as Дата_Рождения,concat(passportdata.passportnum,' ',passportdata.passportwho,' ',passportdata.passportdate,' ',passportdata.pcity,' ',passportdata.pstreet,' ',passportdata.pbuild,'-', passportdata.papt) 
as Pass_Data,op_customers.virtualid as Платежный_ID,users.ip as IP,nethosts.mac as MAC,users.cash as Баланс

FROM users join contracts on users.login=contracts.login join realname on realname.login=users.login 
join phones on users.login=phones.login join op_customers on users.login=op_customers.realid 
join nethosts on users.ip=nethosts.ip left join passportdata on users.login=passportdata.login 
left join address on address.login=users.login 
left join apt on address.aptid=apt.id 
left join build on build.id=apt.buildid 
left join street on street.id=build.streetid 
left join city on city.id=street.cityid order by realname.realname;

 

Ссылка на сообщение
Поделиться на других сайтах

Создайте аккаунт или войдите в него для комментирования

Вы должны быть пользователем, чтобы оставить комментарий

Создать аккаунт

Зарегистрируйтесь для получения аккаунта. Это просто!

Зарегистрировать аккаунт

Вхід

Уже зарегистрированы? Войдите здесь.

Войти сейчас
  • Зараз на сторінці   0 користувачів

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

  • Схожий контент

    • Від sanyadnepr
      Приветствую всех.
      Подскажите пожалуйста где копнуть и нет ли проблемы со стороны протокола взаимодействия сити24 или возможно не учтена необходимая проверка в модуле сити24 в Ubilling, пока писал понял что похоже в проверке payID, но это не точно.  
      Недавно обнаружилось с сити24 начали прилетать дубликаты платежей, в целом платежей мало, два одинаковых запроса Pay с одинаковым transactionID и payID в одну секунду одному платежному ID при этом биллинг "думает" примерно чуть больше минуты и отвечает одним ответом <result>0</result>, сити24 утверждает что ответ они не получили и по протоколу дальше повторяет запросы дублем, биллинг ответ и так по кругу, сити24 спрашивает каким образом с одинаковым payID от сити24 билл продолжает обрабатывать запросы и пополнять абоненту счет раз в 5 минут примерно, на одну и туже сумму, ведь этот payID уже был обработан предполагают сити24 согласно протоколу.
      Конечно есть вопрос к сити24 зачем они дублем присылают два запроса, но они отвечают что эта ситуация учтена в протоколе и проблема на стороне биллинга, потому что он пополняет счет по уже обработанному одинаковому payID.
      При этом transactionID в дублях одинаковый, но с каждым новым дублем разный.
      Если зафаерволить запросы от сити24, но оставить возможность отвечать то после блокировки билл отправляет 2-3 минуты 6 ответов <account>0001</account>  <result>0</result>.
      После снятия блокировки, дубли и платежи нескольких проблемных абонентов прилетают так же по кругу, при этом и с некоторыми новыми пополнениями происходит аналогичная ситуация.
      В openpayz в платежах transactionID и не видно payID.
    • Від nightfly
      Ubilling 1.4.3 rev 9058 The Bladewood Grove
       
      Зміни в структурі БД. alter.ini: нові опції OPHANIMFLOW_ENABLED та OPHANIMFLOW_URLS котрі вмикають та керують інтеграцією з OphanimFlow. alter:ini: нова опція PHOTOSTORAGE_POSTPROCESSING, що вмикає післяобробку зображень при завантаженні в Сховище зображень. alter:ini: нова опція PHOTOSTORAGE_WATERMARK, що вмикає розміщення вотермарки на всіх зображеннях, що завантажуються. alter:ini: нова опція PHOTOSTORAGE_RECOMPRESS, що вмикає зміну компрессії завантажених зображень. alter:ini: нова опція PHOTOSTORAGE_AUTORESIZE, що вмикає автоматичне та лагідне масштабування зображень конячих розмірів. alter:ini: нова опція PHOTOSTORAGE_DRAWIMGINFO, що вмикає вдруковування в зображення відлагоджувальної інформації. alter.ini: нова опція ONDEMAND_CHARTS, що вмикає відкладене завантаження графіків завантаження користувацької смуги. userstats.ini: нова опція OPHANIM_ENABLED, що вмикає інтеграцію OphanimFlow в кабінеті користувача. Модуль Заздрість: тепер авторизаційні дані пристроїв, не відображаються в списку пристроїв. Модуль “Заздрість”: при створенні та редагуванні пристроїв, для полів “пароль” та “enable пароль” тепер використовуються інпути паролів. Модуль “Заздрість”: заздрісним пристроям додано нове поле “Порт”. Тепер в скриптах можна використовувати, відповідний макрос {PORT}. Модуль “Статистика трафіку користувача”: проведено радикальний рефакторинг. Модуль “Статистика трафіку користувача”: додано опційну можливість, відображення трафіку отриманого з OphanimFlow. Модуль “Статистика трафіку користувача”: виправлено проблему невірного відображення залишку коштів на кінець місяця, при використанні Ішимури. Модуль “Статистика трафіку користувача”: додано можливість відображення графіків за останню годину з OphanimFlow. Модуль “Користувачі”: додано опційну можливість, відображення трафіку отриманого з OphanimFlow. Модуль “Сховище зображень”: тепер додатково перевіряє завантажувані зображення на тему їх валідності. Модуль “Фінансові операції”: виправлено відображення суми платежів користувача. Remote API: новий виклик ophanimtraff, який просто бере і синхронізує локальну БД з віддаленими джерелами OphanimFlow. Remote API: виклик userbynum тепер також опційно містить поле з “Платіжним ID” користувача. Глобально: у всіх полях вводу паролів, окрім форми входу, тепер відображається елемент керування “показати/приховати” пароль. Кабінет користувача: в модулі “Трафік” додано опційну можливість, відображення трафіку отриманого з OphanimFlow. Кабінет користувача: в модулі “Трафік” виправлено проблему невірного відображення залишку коштів на кінець місяця, при використанні Ішимури. Кабінет користувача: в модулі “Відеоспостереження” для NVR WolfRecorder замінено розділювач попередньо заповнених даних авторизації. OpenPayz: додано frontend portmonemulti, для отримання платежів від різних контрагентів. Інформацію по контрагентам бере з біллінгу, також використовую розширену інформацію контрагента. Платіжна система в контрагенті мусить бути створена, як PORTMONE 1984tech: додано функціонал генерації RPZ для isc-bind, спасибі @misterromanbush  
      Повний чейнджлог
      Оновлена демка
       

    • Від mac
      Здається, після оновлення PHP 7.4 до PHP 8.2 feesharvester припинив працювати:
       
      /usr/local/bin/curl "http://127.0.0.1/billing/?module=remoteapi&key={SERIAL}&action=feesharvester" <br /> <b>Fatal error</b>: Uncaught TypeError: Unsupported operand types: string - string in {UBPATH}/billing/api/libs/api.fundsflow.php:570 Stack trace: #0 {UBPATH}/billing/modules/remoteapi/feesharvester.php(22): FundsFlow-&gt;harvestFees('2024-01') ...  
      Невеличке розслідування врешті з'ясувало, що це через наявність пробілу у деяких логінах абонентів. Як так сталося? Тому що інколи був неуважно додан трейлінг пробіл до номеру будинка і цей пробіл потрапив до логіну абоненту. Логін абоненту неможливо змінити ніяким чином штатними засобами. Я не розглядаю створення нового абонента для усунення помілки.

      Був обран такий шлях вирішення проблеми. Заміну функції php explode() знайшов у мережі. Мабуть це станеться в нагоді:

       
      diff api.fundsflow.php.bak api.fundsflow.php.new 559c559 < $eachfee = explode(' ', $eachline); --- > $eachfee = preg_split("~(?<!\\\\)(?:\\\\{2})*'[^'\\\\]*(?:\\\\.[^'\\\\]*)*'(*SKIP)(*F)|\s+~s" , $eachline);  
    • Від Dilan
      Собственно ищу кто сделает такую связку с нуля под ключ. Тз высылаю в личку. Заранее спасибо.
    • Від ukrtelekom
      Доброго часу!
      Шукається адміністратор віддалений для разової роботи по коригуванню працюючого Ubilling з мікротами. Якщо стосунки зклєяться- то до постійної додаткової копійки. 
      Всім заздалегідь дякую. Хейти, бажано не писати. Контакти в приватні повідомлення або O73283344O
×
×
  • Створити нове...