«Node.js Virtual Machine (vm) Usage (перевод)» и «MySql»: разница между страницами

Материал из support.qbpro.ru
(Различия между страницами)
imported>Supportadmin
 
imported>Vix
Нет описания правки
 
Строка 1: Строка 1:
==Часть 1==
==Help MySql==
[http://www.davidmclifton.com/2011/08/18/node-js-virtual-machine-vm-usage/ оригинал статьи (англ.)]
* Список пользователей:
SELECT USER from mysql.user;
* Создание пользователя:
CREATE USER 'user'@'localhost' IDENTIFIED BY 'secret';
* Удаление пользователя:
DROP USER user@localhost;
* Предоставить права пользователю:
GRANT ALL PRIVILEGES ON dbname.* TO 'user'@'localhost';
* Предоставить супер права пользователю:
GRANT ALL PRIVILEGES ON dbname.* TO 'user'@'localhost' WITH GRANT OPTION;
* Права равные root для работы через phpmyadmin
GRANT ALL PRIVILEGES ON  *.* TO 'user'@'%' REQUIRE NONE WITH GRANT OPTION MAX_QUERIES_PER_HOUR 0 MAX_CONNECTIONS_PER_HOUR 0 MAX_UPDATES_PER_HOUR 0 MAX_USER_CONNECTIONS 0;


Для моего проекта я хочу иметь возможность запускать изменяющийся код. Возможно есть варианты лучше, чем Node, но самый простой я нашел в базовом модуле '''vm'''. Я немного поэкспериментировал и вот что я обнаружил.
==Настройка PhpMyAdmin==
Процедура «переподключения» phpMyAdmin на работу с внешним сервером достаточно проста, но вызывает вопросы у тех, кто занимается всем этим недавно или неглубоко.


Для использования модуля vm необходимо ‘require’ его:
В данной статье мы рассмотрим несколько вариантов подключения phpMyAdmin ко внешнему серверу, так как задачи и условия у всех разные. В примере я использую сервер баз данных MariaDB, ОС Ubuntu и phpMyAdmin версии 4.5.4, что практически не важно, так как всё достаточно просто. PhpMyAdmin установлен на домашний ПК, но с тем же успехом он может быть настроен и на удалённом сервере. Имеется ввиду, что всё прикладное ПО, такое как непосредственно сам сервер БД, http-сервер и php у вас уже установлено.


<nowiki>var util = require('util');
* Пример первый (доступ с паролем).
var vm = require('vm');</nowiki>
Grabbing util as well in this case just because I prefer the logging methods on it to the standard console.log, as the time stamps help me keep straight what I was running when.


Для теста на скорую руку я сделал hello world.
Сервер баз данных расположен на машине с адресом 10.10.1.10. PhpMyAdmin устанавливаем на локальный ПК с адресом 10.10.1.20. Необходимо убедиться, что сервер баз данных принимает внешние соединения. Правим my.cnf (/etc/mysql/my.cnf). В строке bind-address по умолчанию указан адрес 127.0.0.1, что запрещает серверу принимать внешние соединения. Заменяем его на 0.0.0.0, что разрешит внешние соединения с любого адреса. В целях безопасности лучше уточнить адрес, если вы не планируете подключаться к серверу из разных источников. В этом примере будет использоваться строка следующего вида:


  <nowiki>var util = require('util');
  bind-address = 10.10.1.20
var vm = require('vm');
vm.runInThisContext('var hello = "world";');</nowiki>
 
Таким образом код в строковом параметре компилируется движком JavaScript V8 и выполняется. '''Really cool''', но, к сожалению нет никакого внешнего представления о происходящем. Пусть что-нибудь выводит.
 
вы можете попытаться сделать что-то на подобие:
 
<nowiki>vm.runInThisContext('var hello = "world"; util.log("Hello " + hello);');</nowiki>
 
Однако, вы получите синтаксическую ошибку, говорящую о том, что модуль ‘util’ is not defined. Этому есть очень ''тонкое'' объяснение. the runInThisContext method of vm does use the current context, however it does not have access to local scope, and we defined util in local scope by using the ‘var’ keyword.
 
If you change the first line to remove the ‘var’ keyword, then running it will give a result like so:
 
<nowiki>17 Aug 23:41:32 - Hello world</nowiki>
Anything defined as a global variable is accessible to us with runInThisContext. A good thing if you want to have access to those global variables, a bad thing if you would prefer to limit what the script has access to. For instance, with runInThisContext you can do things like this:
 
<nowiki>vm.runInThisContext('var hello = "world"; console.log("Hello " + hello);');</nowiki>
Assuming this is trusted code, that can be fine – but if it isn’t trusted code, or if (in my case) it is trusted but you want to explicitly encourage it to conform to a set API for interacting with things outside of it, you may wish to exclude the dynamic script you are running from having access to the global context. Fortunately, vm has a method which does this called runInNewContext. For example, this next line will not work because runInNewContext creates a new, ‘empty’ context for the script to run in rather than using the existing one – the script then has access to nothing outside of what JavaScript V8 itself provides – it cannot access global node functions.
 
Fails:
 
<nowiki>vm.runInNewContext('var hello = "world"; console.log("Hello " + hello);');</nowiki>
It will say that ‘console’ is undefined as it no longer has access to the global scope where console is contained.
 
So that is good – we have a way to limit the access the script has, but we need to be able to provide it with something in order to have it effect anything outside of itself and be useful. We do that by providing the context, or ‘sandbox’, for it to use via the optional second argument. Here’s an example:
 
<nowiki>var util = require('util');
var vm = require('vm');
var myContext = {
  hello: "nobody"
}
vm.runInNewContext('hello = "world";', myContext);
util.log('Hello ' + myContext.hello);</nowiki>
The second argument takes an object, the variables of which are injected into the global context of the script. It is my understand that this passing is actually done via some fairly sexy copy operations, so perhaps a relevant performance note to make is that the size of this context is probably a significant factor (will need to do some testing myself to see). Similarly, you can of course pass in functions with the context – those functions may utilize calls outside the sandbox object itself, such as this:
 
<nowiki>var myContext = {
}
myContext.doLog = function(text) {
util.log(text);
}
vm.runInNewContext('doLog("Hello World");', myContext);</nowiki>
And of course we can define whole object structures as such:
 
<nowiki>var myContext = {
  utilFacade: {
  }
}
myContext.utilFacade.doLog = function(text) {
util.log(text);
}
 
vm.runInNewContext('utilFacade.doLog("Hello World");', myContext);</nowiki>
Though I have found at this point we begin to get my JavaScript editor of choice confused about what is legal and what is not.
 
Stepping back for one second, I wanted to note that it is important to think about what is going on here. We are feeding text in, which is compiled at the time runInNewContext. Depending on application, it may not be desired to compile it at the time you run – we might instead want to do this step before hand. This is accomplished via the Script object, like so:
 
<nowiki>var myScript = vm.createScript('var hello = "world";');
myScript.runInNewContext(myContext);
And we can still include calls to our context, so this works fine:
 
var myContext = {
  utilFacade: {
  }
}
myContext.utilFacade.doLog = function(text) {
util.log(text);
}
var myScript = vm.createScript('utilFacade.doLog("Hello World");');
myScript.runInNewContext(myContext);</nowiki>
That said, it is important to understand that this is not very safe, as by the very fact that you are ‘updating’ the context you know there can be leakage – for example:
 
<nowiki>var myScript = vm.createScript('someVariable = "test"; utilFacade.doLog("Hello World");');
myScript.runInNewContext(myContext);
var anotherScript = vm.createScript('utilFacade.doLog(someVariable);');
anotherScript.runInNewContext(myContext);</nowiki>
This will print out ‘test’ to the log. We could have just as easily replaced anything in the context, causing crazy unexpected behavior between executions. Additionally there are some other fundamental unsafe things about this – for instance, our script could consist of a never-ending loop, or a syntax error or similar issue that halts or causes the entire node instance to go into an infinite loop. In general, this simply is not a safe avenue for dealing with untrusted code. I’ve thought about the problem a bit and read some blogs on it, perhaps I’ll post something about what to do in such situation later.
 
For now, I would be remiss if I did not mention this “undocumented” method – not the new method used to create the context, and the associated call differences (passing in the context object instead).
 
<nowiki>var myContext = vm.createContext(myContext);
var myScript = vm.createScript('someVariable = "test"; utilFacade.doLog("Hello World");');
myScript.runInContext(myContext);
var anotherScript = vm.createScript('utilFacade.doLog(someVariable);');
anotherScript.runInContext(myContext);</nowiki>
If you are like me, you may be wondering ‘what is the point? it seems to work similar’ and as far as I can tell currently it pretty much operates the same in terms of functionality – I may be wrong on this point though in some specific use case, if so please feel free to drop a comment on it and I’ll update accordingly.
 
While functionally it seems the same, in reality something very different is occurring under the covers. To get an idea of what, precisely, I think it is worthwhile to consider this git commit somebody made which I think provides some useful reference:
 
[https://gist.github.com/813257 https://gist.github.com/813257]
 
For the lazy, here’s the code:
 
<nowiki>var vm = require('vm'),
  code = 'var square = n * n;',
  fn = new Function('n', code),
  script = vm.createScript(code),
  sandbox;
n = 5;
sandbox = { n: n };
benchmark = function(title, funk) {
  var end, i, start;
  start = new Date;
  for (i = 0; i < 5000; i++) {
    funk();
  }
  end = new Date;
  console.log(title + ': ' + (end - start) + 'ms');
}
var ctx = vm.createContext(sandbox);
benchmark('vm.runInThisContext', function() { vm.runInThisContext(code); });
benchmark('vm.runInNewContext', function() { vm.runInNewContext(code, sandbox); });
benchmark('script.runInThisContext', function() { script.runInThisContext(); });
benchmark('script.runInNewContext', function() { script.runInNewContext(sandbox); });
benchmark('script.runInContext', function() { script.runInContext(ctx); });
benchmark('fn', function() { fn(n); });</nowiki>
This is a pretty simple benchmark script – there are some fundamental issues with it but it gives enough of a view that we can gauge a general sense of relative performance of various methods of executing the script. The script.* functions will use the pre-compiled script whereas the first two will compile at time of execution. The last item is a reference point. Executed on my machine, this gives me the following result:
 
<nowiki>vm.runInThisContext: 127ms
vm.runInNewContext: 1288ms
script.runInThisContext: 3ms
script.runInNewContext: 1110ms
script.runInContext: 23ms
fn: 0ms</nowiki>
So you can see that there are significant performance implications. The pre-compiled examples run faster than those that compile on the fly – no real surprise there – and if we were to increase the number of executions we would find this difference exacerbated. Additionally, we see something significant is happening different with the ‘runInContext’ and ‘runInThisContext’ vs ‘runInNewContext’. The difference being that runInNewContext does exactly what it says – it creates a new context based on the object being passed in. The other two methods use the already created context object, and we can see that there is quite a benefit inherent in this – creating a context is an expensive task.
 
This entry was posted in Javascript, Node.js and tagged coding, javascript, node, node.js, nodejs, programming. Bookmark the permalink.


==Часть 2==
Сохраняем и перезагружаем.
[http://www.davidmclifton.com/2011/08/18/node-vm-continued/ оригинал статьи (англ.)]


One thing I noticed today is that this works:
sudo service mysql restart


<nowiki>var util = require('util');
На ПК (или другой удалённый сервер) устанавливаем phpMyAdmin.
var vm = require('vm');
var contextObject = {
}
contextObject.contextMethod = function(text) {
console.log(text);
}
var myContext = vm.createContext(contextObject);
myContext.contextMethod2 = function(text) {
console.log(text);
}
var scriptText = 'contextMethod("Hello World!"); contextMethod2("Hello Universe!");';
var script = vm.createScript(scriptText);
script.runInContext(myContext);</nowiki>
Which in general makes sense, but it is nice to see that you can modify the context.


==Часть 3 More on Node VM==
sudo apt install phpmyadmin
[http://www.davidmclifton.com/2011/08/18/more-on-node-vm/ оригинал статьи (англ.)]


Posted on August 18, 2011 by David Clifton
В процессе установки отказываемся от конфигурации (конфигурировать нечего; сервер баз данных на удалённой машине).
So I wanted to understand a bit more about what is going on under the covers with Node VM. To do that, I pulled open the node code itself. To start with, when we do a require(‘vm’) we are referencing the builtin vm module, which is contained in Node’s libs folder under the name ‘vm.js’. The code for it is quite simple, so I’ll past it here:


<nowiki>var binding = process.binding('evals');
Далее правим конфигурационный файл phpMyAdmin config.inc.php (/etc/phpmyadmin/config.inc.php). Если это была свежая установка и на локальном хосте нет сервера баз данных, то удаляем все строки (кроме первой «<?php») и пишем следующее:
exports.Script = binding.Script;
exports.createScript = function(code, ctx, name) {
  return new exports.Script(code, ctx, name);
};
exports.createContext = binding.Script.createContext;
exports.runInContext = binding.Script.runInContext;
exports.runInThisContext = binding.Script.runInThisContext;
exports.runInNewContext = binding.Script.runInNewContext;</nowiki>
This is from the version I am currently running which is Node 0.4.9.


What we see here is a call to process.binding to access ‘evals’ in the node C++ code. The rest is mostly just mapping logic, giving us the various methods we have already been using by mapping them to the methods in the C++ code. Pretty simple. To understand what is actually happening here though, we have to jump down into the land of C++.
/* External Server #1 */
  $i++;
  $cfg['Servers'][$i]['verbose'] = 'Server Name';
  $cfg['Servers'][$i]['host'] = '10.10.1.10';
  $cfg['Servers'][$i]['connect_type'] = 'tcp';
  $cfg['Servers'][$i]['extension'] = 'mysqli';
  $cfg['Servers'][$i]['auth_type'] = 'cookie';
  $cfg['Servers'][$i]['AllowNoPassword'] = false;


In the src directory for node, in the file node_script.cc, we find the method that does the real work – WrappedScript::EvalMachine. Taking a look at this, we can get a sense of what differs between passing in a context via runInContext vs runInNewContext and runInThisContext.
Вместо Server Name вписываем что угодно. Сохраняем и закрываем файл.


The first significant time we see a differentiation is here:
==Конвертирование базы из postgresql в mysql==
 
* скачиваем [https://github.com/ChrisLundquist/pg2mysql pg2mysql]
  <nowiki>if (context_flag == newContext) {
    // Create the new context
    context = Context::New();
  } else if (context_flag == userContext) {
    // Use the passed in context
    Local<Object> contextArg = args[sandbox_index]->ToObject();
    WrappedContext *nContext = ObjectWrap::Unwrap<WrappedContext>(sandbox);
    context = nContext->GetV8Context();
  }</nowiki>
We can see that if we do a runInNewContext, we must create a new context object. On the other hand, if we pass in a context object previously created we instead perform a variety of gyrations to ‘unwrap’ the context and get the V8 context of it.


Later, we also find that disposal is quite different:
git clone https://github.com/ChrisLundquist/pg2mysql.git
cd pg2mysql


  <nowiki>if (context_flag == newContext) {
* сохраняем дамп из postgresql ('''пример сохранение всех таблиц для wordpress - wp*''')
    // Clean up, clean up, everybody everywhere!
sudo -u postgres pg_dump --quote-all-identifiers --no-acl --no-owner --table=wp_* --format p --data-only wordpress -f wordpress_pgsql.sql
    context->DetachGlobal();
    context->Exit();
    context.Dispose();
  } else if (context_flag == userContext) {
    // Exit the passed in context.
    context->Exit();
  }</nowiki>
It is clear from our performance results that the object generation and subsequent detach/dispose is expensive enough to make a noticeable difference in our run time.


We also find this code which occurs whether or not a user is doing a new context or passing an existing one:
* конвертируем в формат mysql
php pg2mysql_cli.php worpress_pgsql.sql wordpress_mysql.sql


  <nowiki>// New and user context share code. DRY it up.
* теперь необходимо заменить все таблицы с `"public"."wp_*"` на 'wp_*` это можно сделать в редакторе по F4
  if (context_flag == userContext || context_flag == newContext) {
* не забудьте исправить '''"` (''' на ''''('''
    // Enter the context
* теперь меняем sql команду с INSERT на REPLACE так же по F4
    context->Enter();
* все, дамп можно заливать в базу, предварительно создайте из wordpress начальную структуру таблиц через install и потом вносите данные.
   
   
    // Copy everything from the passed in sandbox (either the persistent
    // context for runInContext(), or the sandbox arg to runInNewContext()).
    keys = sandbox->GetPropertyNames();
   
   
    for (i = 0; i < keys->Length(); i++) {
      Handle<String> key = keys->Get(Integer::New(i))->ToString();
      Handle<Value> value = sandbox->Get(key);
      if (value == sandbox) { value = context->Global(); }
      context->Global()->Set(key, value);
    }
  }</nowiki>
Additionally, there is this set of code which occurs to copy the values back out to the object used from javascript:


  <nowiki>if (context_flag == userContext || context_flag == newContext) {
'''ИСТОЧНИКИ'''
    // success! copy changes back onto the sandbox object.
<hr>
    keys = context->Global()->GetPropertyNames();
* [http://www.opennet.ru/docs/RUS/mysqladm/userman.html Управление пользователями в MySQL]
    for (i = 0; i < keys->Length(); i++) {
* [https://proft.me/2011/07/19/mysql-poleznye-komandy-i-nastrojki/ mysql: полезные команды и настройки ]
      Handle<String> key = keys->Get(Integer::New(i))->ToString();
* [https://www.newalive.net/190-upravlenie-vneshnimi-bazami-dannyh-cherez-phpmyadmin.html PhpMyAdmin]
      Handle<Value> value = context->Global()->Get(key);
<hr>
      if (value == context->Global()) { value = sandbox; }
* [http://gahcep.github.io/blog/2013/03/11/linux-mysql-setup/ Правильная установка и настройка MySQL]
      sandbox->Set(key, value);
* [https://www.hostcms.ru/documentation/server/mysql/ Настройка MySQL]
    }
* [http://linux.mixed-spb.ru/databases/mysql_setup.php Установка и первоначальная настройка MySQL в linux]
  }</nowiki>
* [http://linux.cpms.ru/?p=180 Руководство по MySQL для начинающих]
Looking at all these however, it is important to note that these are if and else if statements – so all of this code (along with a few other tidbits) are ONLY executed if the context is to be new or user provided. There is a third option in the code – which is to say, runInThisContext. None of this code executes in a such a case, which seems consistent with the significant performance difference we see between runInThisContext and the other options.
* [http://cruw.blogspot.ru/2011/11/mysql.html Установка и настройка MySql]
* [https://firstwiki.ru/index.php/%D0%9A%D0%B0%D0%BA_%D0%B7%D0%B0%D0%B3%D1%80%D1%83%D0%B7%D0%B8%D1%82%D1%8C_%D0%B4%D0%B0%D0%BC%D0%BF_MySQL_%D0%B1%D0%B0%D0%B7%D1%8B_%D1%87%D0%B5%D1%80%D0%B5%D0%B7_%D0%BA%D0%BE%D0%BD%D1%81%D0%BE%D0%BB%D1%8C Как загрузить дамп MySQL базы через консоль]
* [https://habr.com/post/105954/ MySQL шпаргалки]
* [https://www.newalive.net/190-upravlenie-vneshnimi-bazami-dannyh-cherez-phpmyadmin.html Управление внешними базами данных через phpMyAdmin]
* [https://geeksmagazine.org/post/7/kak-sozdat-polzovatelya-i-dat-emu-prava-v-mysql Как создать пользователя и дать ему права в MySQL]
* [https://andy-blog.ru/kak-sozdat-novogo-polzovatelya-mysql Как создать нового пользователя MySQL и настроить права доступа ]
* [https://ruhighload.com/%D0%9A%D0%B0%D0%BA+%D0%BD%D0%B0%D1%81%D1%82%D1%80%D0%BE%D0%B8%D1%82%D1%8C+mysql+master-slave+%D1%80%D0%B5%D0%BF%D0%BB%D0%B8%D0%BA%D0%B0%D1%86%D0%B8%D1%8E%3F Как настроить MySQL Master-Slave репликацию?]
* [https://server-gu.ru/mysql-replication-master-slave/ Настройка репликации MySQL MASTER SLAVE]
* [http://blog.anthonyaxenov.ru/2018/10/15/%D1%88%D0%BF%D0%B0%D1%80%D0%B3%D0%B0%D0%BB%D0%BA%D0%B0-master-slave-%D1%80%D0%B5%D0%BF%D0%BB%D0%B8%D0%BA%D0%B0%D1%86%D0%B8%D1%8F-mysql-5-7/ Шпаргалка: Master-slave репликация MySQL 5.7]


It is also important to note that when supplying a context, the way values are communicated back and forth is actually via a copy operation – the scripts is not directly editing the object.
'''ПОЛЕЗНОЕ:'''
<hr>
* [https://www.8host.com/blog/replikaciya-baz-dannyx-mysql-po-tipu-master-slave/ Репликация баз данных MySQL по типу Master/Slave]

Версия от 03:46, 5 мая 2020

Help MySql

  • Список пользователей:
SELECT USER from mysql.user;
  • Создание пользователя:
CREATE USER 'user'@'localhost' IDENTIFIED BY 'secret';
  • Удаление пользователя:
DROP USER user@localhost;
  • Предоставить права пользователю:
GRANT ALL PRIVILEGES ON dbname.* TO 'user'@'localhost';
  • Предоставить супер права пользователю:
GRANT ALL PRIVILEGES ON dbname.* TO 'user'@'localhost' WITH GRANT OPTION;
  • Права равные root для работы через phpmyadmin
GRANT ALL PRIVILEGES ON  *.* TO 'user'@'%' REQUIRE NONE WITH GRANT OPTION MAX_QUERIES_PER_HOUR 0 MAX_CONNECTIONS_PER_HOUR 0 MAX_UPDATES_PER_HOUR 0 MAX_USER_CONNECTIONS 0;

Настройка PhpMyAdmin

Процедура «переподключения» phpMyAdmin на работу с внешним сервером достаточно проста, но вызывает вопросы у тех, кто занимается всем этим недавно или неглубоко.

В данной статье мы рассмотрим несколько вариантов подключения phpMyAdmin ко внешнему серверу, так как задачи и условия у всех разные. В примере я использую сервер баз данных MariaDB, ОС Ubuntu и phpMyAdmin версии 4.5.4, что практически не важно, так как всё достаточно просто. PhpMyAdmin установлен на домашний ПК, но с тем же успехом он может быть настроен и на удалённом сервере. Имеется ввиду, что всё прикладное ПО, такое как непосредственно сам сервер БД, http-сервер и php у вас уже установлено.

  • Пример первый (доступ с паролем).

Сервер баз данных расположен на машине с адресом 10.10.1.10. PhpMyAdmin устанавливаем на локальный ПК с адресом 10.10.1.20. Необходимо убедиться, что сервер баз данных принимает внешние соединения. Правим my.cnf (/etc/mysql/my.cnf). В строке bind-address по умолчанию указан адрес 127.0.0.1, что запрещает серверу принимать внешние соединения. Заменяем его на 0.0.0.0, что разрешит внешние соединения с любого адреса. В целях безопасности лучше уточнить адрес, если вы не планируете подключаться к серверу из разных источников. В этом примере будет использоваться строка следующего вида: 

bind-address		= 10.10.1.20

Сохраняем и перезагружаем. 

sudo service mysql restart

На ПК (или другой удалённый сервер) устанавливаем phpMyAdmin.

sudo apt install phpmyadmin

В процессе установки отказываемся от конфигурации (конфигурировать нечего; сервер баз данных на удалённой машине).

Далее правим конфигурационный файл phpMyAdmin config.inc.php (/etc/phpmyadmin/config.inc.php). Если это была свежая установка и на локальном хосте нет сервера баз данных, то удаляем все строки (кроме первой «<?php») и пишем следующее: 

/* External Server #1 */
 $i++;
 $cfg['Servers'][$i]['verbose'] = 'Server Name';
 $cfg['Servers'][$i]['host'] = '10.10.1.10';
 $cfg['Servers'][$i]['connect_type'] = 'tcp';
 $cfg['Servers'][$i]['extension'] = 'mysqli';
 $cfg['Servers'][$i]['auth_type'] = 'cookie';
 $cfg['Servers'][$i]['AllowNoPassword'] = false;

Вместо Server Name вписываем что угодно. Сохраняем и закрываем файл.

Конвертирование базы из postgresql в mysql

git clone https://github.com/ChrisLundquist/pg2mysql.git 
cd pg2mysql
  • сохраняем дамп из postgresql (пример сохранение всех таблиц для wordpress - wp*)
sudo -u postgres pg_dump --quote-all-identifiers --no-acl --no-owner --table=wp_* --format p --data-only wordpress -f wordpress_pgsql.sql
  • конвертируем в формат mysql
php pg2mysql_cli.php worpress_pgsql.sql wordpress_mysql.sql
  • теперь необходимо заменить все таблицы с `"public"."wp_*"` на 'wp_*` это можно сделать в редакторе по F4
  • не забудьте исправить "` ( на '(
  • теперь меняем sql команду с INSERT на REPLACE так же по F4
  • все, дамп можно заливать в базу, предварительно создайте из wordpress начальную структуру таблиц через install и потом вносите данные.


ИСТОЧНИКИ

ПОЛЕЗНОЕ:

Источник — https://support.qbpro.ru/index.php?title=Node.js_Virtual_Machine_(vm)_Usage_(перевод)&oldid=2653