[Spce-user] Problem: Found 1 failed service(s): ngcp-mediator

[Rickey]

The cause was most likely a bug in the redis database. After backing up the
files in /ngcp-data/redis
and:
# redis-cli
# select 21
# flushdb
# quit
# systemctl start ngcp-mediator.service

The ngcp-mediator service is functioning properly.
Is it possible to restore missing CDRs from a copy of the files: spce.aof
spce.rdb?

BR,
Rickey

śr., 8 cze 2022 o 13:08 Rickey <rickey58 at gmail.com> napisał(a):

> Good day,
>
> After running ngcp-status, it says there is a problem with the
> ngcp-mediator service.
>
> In the table: accounting.cdr, there are actually no new calls.
> After restarting the service:
>
> *systemctl start ngcp-mediator.service*
> I get the following log error: /var/log/ngcp/cdr.log
> Jun 8 12:21:05 spce (notice) mediator [32290]: mediator.c: 191 [main]:
> Starting mediator
> Jun 8 12:21:05 spce (info) mediator [32290]: mediator.c: 223 [main]: ACC
> acc database host = 'localhost', port = '3306', user = 'kamailio', name =
> 'kamailio '
> Jun 8 12:21:05 spce (info) mediator [32290]: mediator.c: 225 [main]: CDR
> acc database host = 'localhost', port = '3306', user = 'mediator', name =
> 'accounting '
> Jun 8 12:21:05 spce (info) mediator [32290]: mediator.c: 227 [main]: PROV
> database host = 'localhost', port = '3306', user = 'mediator', name =
> 'provisioning'
> Jun 8 12:21:05 spce (info) mediator [32290]: mediator.c: 229 [main]: STATS
> database host = 'localhost', port = '3306', user = 'mediator', name =
> 'stats'
> Jun 8 12:21:05 spce (info) mediator [32290]: mediator.c: 233 [main]: REDIS
> database host = 'localhost', port = '6379', pass = '<none>', id = ' 21 '
> Jun 8 12:21:05 spce (notice) mediator [32290]: mediator.c: 247 [main]: Up
> and running, daemonized = 0, pid-path = '/ run / ngcp-mediator.pid',
> interval = 10
>
> *Jun 8 12:21:09 spce (crit) mediator [32290]: medmysql.c: 1510
> [medmysql_flush_med_str]: Error executing query: Data truncated for column
> 'call_status' at row 597*Jun 8 12:21:09 spce (info) mediator [32290]:
> mediator.c: 465 [main]: Shutting down.
> Jun 8 12:21:09 spce (warning) mediator [32290]: medmysql.c: 510
> [medmysql_handler_close]: Closing DB handle with still 4 statements in queue
> Jun 8 12:21:09 spce (warning) mediator [32290]: medmysql.c: 510
> [medmysql_handler_close]: Closing DB handle with still 2 statements in queue
> Jun 8 12:21:09 spce (info) mediator [32290]: mediator.c: 473 [main]:
> Successfully shut down.
>
> When trying to start the service again with the -l option:
>
> */usr/bin/ngcp-mediator -l*
> in the log: /var/log/ngcp/cdr-query.log
> ~ 3860 calls are saved.
>
> The only thing that bothers me is the fact that there are a total of 2
> insert queries in this file, separated by a comma (instead of a semicolon):
>
> *#line no.1:*insert into cdr (id, update_time, source_user_id,
> source_provider_id, source_external_subscriber_id,
> source_external_contract_id, source_account_id, source_user, source_domain,
> source_cli, source_clir, source_ip, destination_user_id,
> destination_provider_id, destination_external_subscriber_id,
> destination_external_contract_id, destination_account_id, destination_user,
> destination_domain, destination_user_in, destination_domain_in,
> destination_user_dialed, peer_auth_user, peer_auth_realm, call_type,
> call_status, call_code, init_time, start_time, duration, call_id,
> source_carrier_cost, source_reseller_cost, source_customer_cost,
> destination_carrier_cost, destination_reseller_cost,
> destination_customer_cost, split, source_gpp0, source_gpp1, source_gpp2,
> source_gpp3, source_gpp4, source_gpp5, source_gpp6, source_gpp7,
> source_gpp8, source_gpp9, destination_gpp0, destination_gpp1,
> destination_gpp2, destination_gpp3, destination_gpp4, destination_gpp5,
> destination_gpp6, destination_gpp7, dest ination_gpp8, destination_gpp9,
> source_lnp_prefix, destination_lnp_prefix, source_user_out,
> destination_user_out, source_lnp_type, destination_lnp_type) values (...),
> (~ 1930 calls queries)*,*
>
> * #line no. 1931:*insert into cdr (id, update_time, source_user_id,
> source_provider_id, source_external_subscriber_id,
> source_external_contract_id, source_account_id, source_user, source_domain,
> source_cli, source_clir, source_ip, destination_user_id,
> destination_provider_id, destination_external_subscriber_id,
> destination_external_contract_id, destination_account_id, destination_user,
> destination_domain, destination_user_in, destination_domain_in,
> destination_user_dialed, peer_auth_user, peer_auth_realm, call_type,
> call_status, call_code, init_time, start_time, duration, call_id,
> source_carrier_cost, source_reseller_cost, source_customer_cost,
> destination_carrier_cost, destination_reseller_cost,
> destination_customer_cost, split, source_gpp0, source_gpp1, source_gpp2,
> source_gpp3, source_gpp4, source_gpp5, source_gpp6, source_gpp7,
> source_gpp8, source_gpp9, destination_gpp0, destination_gpp1,
> destination_gpp2, destination_gpp3, destination_gpp4, destination_gpp5,
> destination_gpp6, destination_gpp7, dest ination_gpp8, destination_gpp9,
> source_lnp_prefix, destination_lnp_prefix, source_user_out,
> destination_user_out, source_lnp_type, destination_lnp_type) values (...),
> (~ antoher 1930 calls)*,*
>
> When manually queried from this file, the records load correctly.
> What could be the problem and how do I fix it?
>
> BR,
> Rickey
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sipwise.com/pipermail/spce-user_lists.sipwise.com/attachments/20220608/09f541e7/attachment-0002.html>