backup and restore after migration error

[Szabolcs Sandor]

After migration I cannot backup and restore database.

[Warning] Aborted connection  to db: ‚otobo‘ user: ‚root‘ host: ‚localhost‘ (Got an error writing communication packets)

I have already increase some mysql parameters like wait_timeout, net_read_timeout, net_write_timeout. I also have checked database.

 

Any suggestion?

Thank You for help.

Szabolcs

[Szabolcs Sandor]

Hi!

mysqldump stopped at article_data_mime_attachment table. I don’t know which parameters should modify in the MariaDB.

 

Table size in MB is next:

+——————————–+———–+
| article_data_mime_attachment | 3498.02 |
| ticket_history | 263.48 |
| article_data_mime_plain | 261.14 |
| article_search_index | 104.72 |
| article_data_mime | 86.67 |
| package_repository | 48.53 |
| article_flag | 40.09 |
| article | 31.61 |
| ticket | 20.14 |
| dynamic_field_value | 13.58 |
| sysconfig_deployment | 10.53 |
| sysconfig_default_version | 8.86 |
| service_customer_user | 8.06 |
| ticket_flag | 7.58 |
| sysconfig_default | 6.86 |
| generic_agent_jobs | 1.86 |
| xml_storage | 0.81 |
| customer_preferences | 0.31 |
| change_workorder | 0.22 |
| change_item | 0.22 |
| change_notification_message | 0.19 |
| queue | 0.16 |
| condition_action | 0.16 |
| search_profile | 0.14 |
| notification_event_message | 0.14 |
| condition_expression | 0.13 |
| configitem | 0.13 |
| user_preferences | 0.11 |
| auto_response | 0.11 |
| sysconfig_modified_version | 0.11 |
| change_cip_allocate | 0.09 |
| stats_report | 0.09 |
| change_history | 0.09 |
| ticket_state | 0.09 |
| change_condition | 0.09 |
| link_relation | 0.09 |
| calendar | 0.09 |
| configitem_version | 0.09 |
| signature | 0.08 |
| configitem_history_type | 0.08 |
| group_customer | 0.08 |
| auto_response_type | 0.08 |
| gi_webservice_config | 0.08 |
| time_accounting | 0.08 |
| communication_log | 0.08 |
| customer_user | 0.08 |
| ticket_type | 0.08 |
| customer_user_customer | 0.08 |
| dynamic_field | 0.08 |
| follow_up_possible | 0.08 |
| role_user | 0.08 |
| link_type | 0.08 |
| group_role | 0.08 |
| standard_template_attachment | 0.08 |
| ticket_watcher | 0.08 |
| notification_event | 0.08 |
| sysconfig_modified | 0.08 |
| cloud_service_config | 0.08 |
| standard_template | 0.08 |
| ticket_history_type | 0.08 |
| salutation | 0.08 |
| group_customer_user | 0.08 |
| link_state | 0.08 |
| change_history_type | 0.08 |
| users | 0.08 |
| article_sender_type | 0.08 |
| queue_auto_response | 0.08 |
| roles | 0.08 |
| groups_table | 0.08 |
| standard_attachment | 0.08 |
| gi_webservice_config_history | 0.08 |
| acl | 0.08 |
| communication_channel | 0.08 |
| calendar_appointment | 0.08 |
| ticket_lock_type | 0.08 |
| group_user | 0.08 |
| article_data_mime_send_error | 0.08 |
| calendar_appointment_ticket | 0.08 |
| queue_standard_template | 0.08 |
| ticket_priority | 0.06 |
| pm_activity | 0.06 |
| gi_debugger_entry_content | 0.06 |
| ticket_index | 0.06 |
| scheduler_recurrent_task | 0.06 |
| pm_activity_dialog | 0.06 |
| change_template | 0.06 |
| pm_transition | 0.06 |
| mail_queue | 0.06 |
| notification_event_item | 0.06 |
| scheduler_future_task | 0.06 |
| system_address | 0.06 |
| sla | 0.06 |
| system_maintenance | 0.06 |
| configitem_history | 0.06 |
| general_catalog | 0.06 |
| change_notification_rec | 0.06 |
| communication_log_object | 0.06 |
| cip_allocate | 0.06 |
| pm_transition_action | 0.06 |
| pm_process | 0.06 |
| form_draft | 0.06 |
| ticket_state_type | 0.06 |
| service | 0.06 |
| gi_debugger_entry | 0.06 |
| mail_account | 0.06 |
| valid | 0.06 |
| change_notification | 0.06 |
| scheduler_task | 0.06 |
| personal_services | 0.05 |
| change_template_type | 0.05 |
| change_cab | 0.05 |
| virtual_fs | 0.05 |
| communication_log_object_entry | 0.05 |
| sessions | 0.05 |
| system_data | 0.05 |
| ticket_number_counter | 0.05 |
| imexport_template | 0.05 |
| virtual_fs_preferences | 0.05 |
| smime_signer_cert_relations | 0.05 |
| change_number_counter | 0.05 |
| personal_queues | 0.05 |
| configitem_definition | 0.05 |
| communication_log_obj_lookup | 0.05 |
| ticket_loop_protection | 0.05 |
| condition_operator | 0.03 |
| ticket_lock_index | 0.03 |
| sysconfig_deployment_lock | 0.03 |
| service_preferences | 0.03 |
| change_state_machine | 0.03 |
| sla_preferences | 0.03 |
| imexport_format | 0.03 |
| postmaster_filter | 0.03 |
| condition_attribute | 0.03 |
| dynamic_field_obj_id_name | 0.03 |
| general_catalog_preferences | 0.03 |
| imexport_mapping | 0.03 |
| customer_company | 0.03 |
| data_storage | 0.03 |
| imexport_search | 0.03 |
| service_sla | 0.03 |
| article_data_otobo_chat | 0.03 |
| condition_object | 0.03 |
| queue_preferences | 0.03 |
| imexport_mapping_format | 0.03 |
| imexport_object | 0.03 |
| virtual_fs_db | 0.03 |
| imexport_mapping_object | 0.03 |
| link_object | 0.03 |
| process_id | 0.02 |
| change_notification_grps | 0.02 |
| configitem_counter | 0.02 |
| acl_sync | 0.02 |
| pm_entity_sync | 0.02 |
| web_upload_cache | 0.02 |
+——————————–+———–+
154 rows in set (0.003 sec)

 

article_data_mime_attachment = 3,610509432 Gigabytes

MariaDB [otobo]> SELECT SUM(content_size) from article_data_mime_attachment;
+——————-+
| SUM(content_size) |
+——————-+
| 3610509432 |
+——————-+

 

Thank You for your help.

Szabolcs

 

[Szabolcs Sandor]

Fortunately I have managed to solve to migrate database. Before load back database I have modified some mysql parameters.

I have logged in my mysql database as root and set the next max values.

> docker exec -it  otobo-web-1 bash
> mysql -h db -u root -p

SET SESSION wait_timeout=31536000;
SET SESSION wait_timeout=31536000;
SET GLOBAL interactive_timeout=31536000;
SET GLOBAL max_allowed_packet=1073741824;

My  migration steps:

1.)  Install otobo docker version.  Create the same config as I have used in  otrs. Install packages what I have used in otrs.

2.) Use  script to migrate db on otobo-web-1 container. ( 5.14.2 Optional Step: Streamlined migration of the database (only for experts and
spezial scenarios) )

scripts/backup.pl -t migratefromotrs --max-allowed-packet 1G --db-name otrs --db-host=x.x.x.x --db-user dbadmin --db-password PASSWORD

3.) Reload database on otobo-web-1 from the directory where migration createed sql files.

mysql -h db --debug-check --debug-info --max-allowed-packet=1073741824 -u otobo -p otobo < otrs_pre.sql

At the bottom I managed to migrate database.

Szabolcs

 

 

 

[Author]

Posts