Bench restore fails, mysql restore succeeds

1

I have a database backup that’s about 13-14mb compressed, 93mb uncompressed. Bench restore fails with “SyntaxError: unexpected EOF while parsing”. Copying the uncompressed .sql file into the mariadb container and running "mysql -u root -p [database_name] < [backup_file_name]-database.sql succeeds without error.

I used to be able to use bench restore and it would work. And it still does in a new site with not much data. Have I already crossed the line into “large database” territory where bench restore is not expected to work?

This is on the latest v.13:
erpnext 13.52.1
frappe 13.57.4

Here’s the full traceback:

Traceback (most recent call last):
  File "/usr/local/lib/python3.9/runpy.py", line 197, in _run_module_as_main
    return _run_code(code, main_globals, None,
  File "/usr/local/lib/python3.9/runpy.py", line 87, in _run_code
    exec(code, run_globals)
  File "/home/frappe/frappe-bench/apps/frappe/frappe/utils/bench_helper.py", line 110, in <module>
    main()
  File "/home/frappe/frappe-bench/apps/frappe/frappe/utils/bench_helper.py", line 20, in main
    click.Group(commands=commands)(prog_name="bench")
  File "/home/frappe/frappe-bench/env/lib/python3.9/site-packages/click/core.py", line 829, in __call__
    return self.main(*args, **kwargs)
  File "/home/frappe/frappe-bench/env/lib/python3.9/site-packages/click/core.py", line 782, in main
    rv = self.invoke(ctx)
  File "/home/frappe/frappe-bench/env/lib/python3.9/site-packages/click/core.py", line 1259, in invoke
    return _process_result(sub_ctx.command.invoke(sub_ctx))
  File "/home/frappe/frappe-bench/env/lib/python3.9/site-packages/click/core.py", line 1259, in invoke
    return _process_result(sub_ctx.command.invoke(sub_ctx))
  File "/home/frappe/frappe-bench/env/lib/python3.9/site-packages/click/core.py", line 1066, in invoke
    return ctx.invoke(self.callback, **ctx.params)
  File "/home/frappe/frappe-bench/env/lib/python3.9/site-packages/click/core.py", line 610, in invoke
    return callback(*args, **kwargs)
  File "/home/frappe/frappe-bench/env/lib/python3.9/site-packages/click/decorators.py", line 21, in new_func
    return f(get_current_context(), *args, **kwargs)
  File "/home/frappe/frappe-bench/apps/frappe/frappe/commands/__init__.py", line 31, in _func
    ret = f(frappe._dict(ctx.obj), *args, **kwargs)
  File "/home/frappe/frappe-bench/apps/frappe/frappe/commands/site.py", line 166, in restore
    if not force and is_downgrade(decompressed_file_name, verbose=True):
  File "/home/frappe/frappe-bench/apps/frappe/frappe/installer.py", line 612, in is_downgrade
    app_rows = frappe.safe_eval(line)
  File "/home/frappe/frappe-bench/apps/frappe/frappe/__init__.py", line 2121, in safe_eval
    return eval(code, eval_globals, eval_locals)
  File "<string>", line 0

SyntaxError: unexpected EOF while parsing
2

seems to indicate that OEL/EOF markers had a problem with \r\n vs \n.
Alternatively, maybe the encoding is not UTF and bench detects this, while the CLI lets it through?
It may also be that the overhead of bench used more resources than the CLI did, so it was able to complete the process.

Database size should not make any difference as long as the hardware/resources are sufficient to handle the data volume.

3

Thanks, @trentmu. So that would indicate that somewhere in the sql dump there is a line-ending issue? Would that indicate an issue somewhere in the data being backed up?

4

More info… it does seem as if there is some kind of EOL/EOF marker issue on line 2 of the sql dump generated by “bench backup” as it is read by “bench restore”.

If I do a manual mariadb-dump/mysqldump and run bench restore from it, there is no error. Just as when I do a “bench backup” and restore manually with mysql. Strange thing is it’s not repeatable in a new bench/new site.

5

I’m giving up on this issue (and bench backup) for now. Everything works using mariadb-dump directly in the mariadb container instead of from the backend container’s bench backup. I’m assuming the problem has something to do with running over the docker network since I get the same results running mariadb-dump from the backend container.