Jump to content

Дублирующая оплата


Recommended Posts

скорее всего получилось из за того что: было добавлено две подсети, 192.168.110.33/29 и 192.168.110.33/27

после чего добавлен был пользователь на ип 192.168.110.39, когда обнаружилась ошибка, подсеть 192.168.110.33/27 грохнули, а пользователь остался с ип 192.168.110.39.. после чего были попытки изменить ип вручную, выбор из другого диапазона, удаление пользователя и т.п.., в таблице nethosts удалилась запись с мак-ип. сейчас добавил в данную таблицу мак пользователя и ип из правильной подсети, дополнительно в таблице users этому пользователю назначил тот же ип что и добавлял в таблицу nethosts..  больше ничего не делалось..

Link to post
Share on other sites

скорее всего получилось из за того что: было добавлено две подсети, 192.168.110.33/29 и 192.168.110.33/27

после чего добавлен был пользователь на ип 192.168.110.39, когда обнаружилась ошибка, подсеть 192.168.110.33/27 грохнули, а пользователь остался с ип 192.168.110.39.. после чего были попытки изменить ип вручную, выбор из другого диапазона, удаление пользователя и т.п.., в таблице nethosts удалилась запись с мак-ип. сейчас добавил в данную таблицу мак пользователя и ип из правильной подсети, дополнительно в таблице users этому пользователю назначил тот же ип что и добавлял в таблицу nethosts..  больше ничего не делалось..

В таблицу users писать самому - очень плохая идея. Ибо с ней напрямую работает stargazer. Манипуляции с таблицей users идут только через stargazer, взаимодействие со stargazer идет через sgconf/sgconf_xml.

Чем оно вам обернется - я хз, смотрите логи старгейзера. Не один раз уже говорилось, что нельзя трогать users при живом stargazer.

Че то вот смотрю и не пойму, как вы сеть грохнули до смены ипишки юзеру. Ибо есть вполне себе говорящий кусок кода при удалении сети:

if (!multinet_network_is_used($network_id)) {

Ручками чтоль из БД удалили?

Edited by l1ght
Link to post
Share on other sites

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

Link to post
Share on other sites

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

Там вполне конкретная привязка по ID сети, а не к маске, всё равно не понимаю, как у вас так получилось.

Link to post
Share on other sites

сам не понял что к чему, однако после перезагрузки сервера проблема возобновилась.. хотя все пользователи которые были "сломаны" - сейчас нормально, однако ни кредит не ставится, ни оплата не вносится..

Link to post
Share on other sites
  • 7 months later...
  • 3 months later...
On 17.01.2018 at 1:58 PM, cetim said:

Не создавая новую тему.

Сегодня прилетела дублирующая оплата по карточке пополнения

duble_pay.thumb.PNG.98fb5fb5e4cc540deb239b76c78b4a42.PNG

 

Вирішили проблему, бо в мене те ж саме тільки з банками?

Edited by ppv
Link to post
Share on other sites
6 часов назад, ppv сказал:

Вирішили проблему, бо в мене те ж саме тільки з банками?

Не таке саме і не тільки з банками. Можна звичайно добитись відсутності тормозів в роботі вашої ж бази, повключати нормально кешування... А ще давно вже є радикальне рішення для лінивих які не хочуть чи не можуть нормально це зробити.

Link to post
Share on other sites
13 hours ago, nightfly said:

Не таке саме і не тільки з банками. Можна звичайно добитись відсутності тормозів в роботі вашої ж бази, повключати нормально кешування... А ще давно вже є радикальне рішення для лінивих які не хочуть чи не можуть нормально це зробити.

 

Декілька питань:

QUERY_CACHE_TYPE = ON чи DEMAND

 

і чи хватить стандартних значень

query_cache_size

query_cache_limit

mysql> SHOW VARIABLES LIKE 'query_cache_%';

+------------------------------+----------+
| Variable_name                | Value    |
+------------------------------+----------+
| query_cache_limit            | 1048576  |
| query_cache_min_res_unit     | 4096     |
| query_cache_size             | 1048576 |
| query_cache_type             | OFF       |
| query_cache_wlock_invalidate | OFF      |
+------------------------------+----------+
5 rows in set (0.00 sec)

 

Link to post
Share on other sites
1 hour ago, nightfly said:

З такими запитаннями, краще не чіпайте MySQL взагалі.

До відповіді ще почитав, згідний що дурне питання. Але можна було адекватніше, хоча б кинути зсилку документації чи щось таке, чи написати вчи матчасть )

 

 

Link to post
Share on other sites
24 минуты назад, ppv сказал:

До відповіді ще почитав, згідний що дурне питання. Але можна було адекватніше, хоча б кинути зсилку документації чи щось таке, чи написати вчи матчасть )

 

 

Вы спрашивате
"хочу дивжок перебрать. мне его отверткой колупать или сразу кувалдой по нему хуячить?"

а вы потом обижаетесь, что вам не посоветовали отвертку в ж#пу засунуть \_(-_-)_/

 

И да, вам дали вполне конкретную ссылку, как решить проблему

  • Thanks 1
Link to post
Share on other sites
39 минут назад, ppv сказал:

Але можна було адекватніше

Типу одразу наxyй послати? Так - можна.

 

39 минут назад, ppv сказал:

чи написати вчи матчасть )

Вчи матчасть.

Edited by nightfly
Оо
  • Haha 1
Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Recently Browsing   0 members

    No registered users viewing this page.

  • Similar Content

    • By Tris
      В противоположность теме https://local.com.ua/forum/topic/94735-%D0%B4%D1%83%D0%B1%D0%BB%D0%B8%D1%80%D1%83%D1%8E%D1%89%D0%B0%D1%8F-%D0%BE%D0%BF%D0%BB%D0%B0%D1%82%D0%B0 была отмечена проблема:
       при мгновенном (точность до 1 сек. = предел точности отображения даты в MySQL) занесении нескольких (2+) платежей одному абоненту (например - при импорте банковских выписок) происходит следующее:
      в логе старгейзера присутствуют оба (или более) платежа, в БД, таблице bankstaparsed, присутствуют оба (или более) платежа, в БД, таблице payments присутствуют оба (или более) платежа (!!!), НО одновременно - в карточке пользователя отсутствуют все платежи, кроме последнего за эту дату (сужу по ID lifestory) как результат - не хватает средств у конкретной учётной записи => отключён инет.  Такое ощущение, что где-то в скриптах, касасающихся карточки абонента, в SQL-запросах добавлен оператор GROUP BY  (или что-либо подобное) и происходит как раз вышесказанное (группирует-режет записи). При беглом осмотре файлов - такого не нашёл.
       Поэтому просьба к тем, кто более сведущ что с чем взаимосвязано в уБиллинге: где искать (в каких файлах-скриптах) проблему не учёта средств клиента, если:
      module=report_finance - отображает данные верно module=lifestory - отображает данные верно module=addcash - отображает данные верно module=pl_fundsflow - ошибка, потеря записей (с одинаковой датой) итоговая сумма средств абонента меньше, чем занесено в БД. P.S.: модуль онлайн и что-то в карточке абонента "рихтовано", но не мной.
×
×
  • Create New...