tried to serach in documentation but I have a lot of doubts...
I'm running ejabberd version 2.1.9 on an old debian server (5.0.8) with more than 500 users...
Now I was asked to update to the latest version, but I need some advice;
in the documentation I saw there are specific upgrade instructions between versions also from 2.1.x to 16.02
if I upgrade to 16 version can I jump directly to 22.10 or I have to upgrade to every intermediate releases?
or as an alternative, is possible to export users, passowrds, shared rooster ecc..and restore them on a fresh installed 22.10 ?
#badlop
Thank you very much for detailed info :-)
but I'm stuck with backup database... If I use the plain text backup "ejabberdctl dump" give me errors importing table "pubsub_node" on the new server
** Table pubsub_node already exists on ejabberd#localhost, just entering data
Problem 'error {case_clause,
{aborted,
{bad_type,
{pubsub_item,
{"751ca223b3f58d185f3afef05d0e3d4eb236c376",218},
{{1317,45407,740776},{"donkeykong","acme.com",[]}},
{{1317,133197,815914},
{"donkeykong","acme.com","stc"}},
[{xmlelement,"metadata",
[{"xmlns","urn:xmpp:avatar:metadata"}],
[{xmlelement,"info",
[{"id","751ca223b3f58d185f3afef05d0e3d4eb236c376"},
{"type","image/png"},
{"bytes","16541"},
{"width","96"},
{"height","94"}],
[]}]}]}}}}' occurred executing the command.
Stacktrace: [{ejabberd_admin,load_mnesia,1},
{ejabberd_ctl,call_command,3},
{ejabberd_ctl,try_call_command,3},
{ejabberd_ctl,process2,3},
{ejabberd_ctl,process,1},
{rpc,'-handle_call_call/6-fun-0-',5}]
tried editing and removing the pubsub_item, but the problem will show on the next pubsub_item.
If I try to use "ejabberdctl backup" the server reply with this error
Can't store backup in "/tmp/jabba.backup" at node ejabberd#jabba: {"Cannot prepare checkpoint (replica not available)",
[temporarily_blocked,
{{1670,
255465,
408029},
ejabberd#jabba}]}
even if I have only one node
The import error of dump came up even if I try to make a little jump from 2.1.9 to 2.1.13
any Suggestion?
with more than 500 users
An ejabberd server with around 500 online users? That's a small server, I guess you don't even use SQL database, so that's one less thing to worry about.
An ejabberd deployment is composed of:
the code (source or binary)
configuration file (or files)
mnesia internal database, that is stored in the mnesia spool dir (see system install)
SQL database (if you configure it)
log files (only useful for your interest and consult)
When upgrading ejabberd code, it is usual that the release notes mention some changes in the configuration, and some changes in SQL schemas. The changes in the mnesia internal database are implemented inside ejabberd and applied automatically when needed.
I have to upgrade to every intermediate releases?
In general no need. In general when jumping a few releases, you just read the release notes and apply the configuration and SQL schema changes of all the intermediate releases.
But in your case... as it's a big jump, I recommend you to not touch the production server yet. First test the upgrade in another machine (your personal machine, or other unused server, or a laptop, or a docker container...), so you learn how to do it perfectly without annoying the users.
There are many ways; but I were you, or if I were sitting in a chair next to you, this is how I would do it. I would be optimistic and try to jump from from 2.1.9 to 22.10, but slowly, and using a temporary server for testing the process and learning:
In a testing machine install the desired ejabberd version (22.10 or whatever). It should work perfectly, as it's empty and has default configuration. Notice most XMPP clients allow you to login to an account whatever#example.com specifying the IP address and port of the server: in your case you will have to specify the IP address of the new ejabberd server, as the XMPP domain it doesn't match the DNS name.
Obviously, the configuration in the new server will lack customizations that are essential for you (the served domain, what accounts are admins, certificate files, port numbers, custom modules...)
Copy the old configuration file to the new server. Notice they use different formats (ejabberd.cfg in erlang format... and ejabberd.yml in YAML format).
Manually and slowly apply one of your customizations in the new configuration file. Restart ejabberd, check it starts and works correctly, and then repeat with another customization.
Now you have a new ejabberd server running, with all (or most) of your desired configuration. Two things are lacking: the users data, and of course replacing the old ejabberd with the new ejabberd.
In the production ejabberd server, export the mnesia database using "ejabberdctl backup" and "ejabberdctl dump" (better to have two alternatives, in case one doesn't work). Copy those files to the machine that has the new ejabberd server.
In the new ejabberd, run restore specifying the binary backup
(or load specifying the text dump). With some luck, this will end correctly.
Restart ejabberd. It will notice that the mnesia tables use very old schemas, and will automatically update them. This may take a while. With some luck it will end correctly.
If steps 7 or 8 fail, and you are lucky to know what username or what data is problematic, you can try to delete or "fix" that in the text dump file before loading it).
Once you are happy with the new ejabberd server (the new configuration looks great, has all your customizations, and all the users are correctly imported), then it's time to replace the old ejabberd with the new one.
Alternatively, you can try to upgrade from 2.1.9 to 16.02, and later from 16.02 to 22.10
In any case, general recommendations:
take it slowly because there are many steps
be patient because you may face small problems that require fixing before continuing to the next step
be kind to yourself because you never did this
annotate every major problem you face, and how you fixed it (in case you find this problem again this day or in the next days, or eventually somebody else in your organization)
be sure this can be done (in the worst case, with a progressive upgrade from one version to the next :)
I've been teaching myself GraphQL using Prisma -- very much a beginner at both.
I just got a programming test where the brief is to connect a React Native frontend to a WordPress backend. I thought this might be a fun opportunity to put some Prisma and GraphQL into practice. My thought was to connect Prisma to the WP MySQL DB and then use Prisma-GraphQL to connect to React Native.
However, it seems that connecting Prisma to MySQL isn't so straightforward -- at least for me, a beginner. I'd welcome any info as to how one might go about this -- not detailed code, of course, but more whether it's reasonable to do what I'm thinking of, and what packages/route would be the best way forward. Thanks!
An easy answer would be: All you need to connect Prisma to any MySQL database is a Host and a port(3306 because this is MYSQL) of where the DB is running.
And this leads us to where do you have your Prisma Server running?
if you are just a front-end dev and you don't know or don't wanna deal with stuff like docker then you better off using something like Prisma Cloud which will provision a Prisma server for you and can also host the MySQL Database for you or you can host it yourself and choose the have an existing database option and provide the hostname(URL) where you have it during creating your Prisma server.
on the other hand, if you comfortable running it locally or on a cloud provider with Docker(Local Prisma Setup) then you just provide the host and port as you can see in the docs link above in your docker-compose configuration file to Prism.
update:
Regard connecting to an existing DB, If you tried to do a prisma deploy on a DB with a different schema it probably gonna blow and complain about the schema conflict, that's why you need introspection for before but as you mentioned in the comment it's only for PostgreSQL at the moment, they are working on creating a tool for MySQL but it's no one knows when it could be out you can check for updates on the open issue with this feature here
hope this can help simplify things a bit.
For learning project you can do choose any solution. You will have fun and pain with MySQL shared between Prisma/ReactNative and WordPress.
For real project, you should avoid sharing one DataBase between different applications. In your case right architect decision is using WPGraphQL instead Prisma. It will provide you GraphQL from the WordPress Plugin.
So I am developing an app that I want to let include server interaction. I have installed MySQL server and MySQL Workbench. I am able to query my data base locally from Java. such as local host. but when I change the query correctly, to reference the IP of my server and not "localhost", I am unsuccessful both on my server and separate machine. I have pinged my server from my another machine successfully. I have configured user accounts on MySQL workbench in almost every way possible. I have done a lot of googling with little success.
I am 19 and just starting to learn SQl now. It'sn ot a big part of my project. I am sorry if this sounds like a basic question, but google has gotten me no where and I am really eager to publish my app xP . So I would really appreciate the help or even a basic guide as to what I may be doing wrong.
Most likely, this is because you did not yet assign user permissions for remote computers. You'd have to use something like tyhe following:
GRANT SELECT ON myDatabase.*
TO myUser#’mycomputers.ip.address’ IDENTIFIED BY ‘my_password’;
There's a more extensive guide here:
https://support.rackspace.com/how-to/mysql-connect-to-your-database-remotely/
I'm new to Couchbase. Does anyone know how to connect between Couchbase (CB) servers in order to migrate data? I want to migrate data from a production CB server to my local server.
I found here how to migrate between buckets, but within the same server.
Also, I could do the migration between different servers using a backend application (I'm using C#.Net) using N1QL, but I want to learn how to do the server to server migration since it is a pretty standard and common operation .
Many thanks in advance.
Do you need continuous migration? Or backup/restore would be enough?
If latter, you can use cbbackup/cbrestore tools http://developer.couchbase.com/documentation/server/current/backup-restore/backup-restore.html
Either cbbackup and/or cbrestore or just turning on XDCR to get the changes from production to your local server would work too.
Definitely some security implications on doing this, but that's up to you to figure out! :)
Thanks to #Ade Stringer who finally gave me the best solution, which is to use the cbtransfer tool. This tool simply needs the source and target urls of the servers (and the names of the buckets), which is ideal since -- in general-- one doesn't have access to the file system of the servers.
Here is a sample call:
cbtransfer http://10.10.10.68:8091 http://localhost:8091 -b SourceBucketName --bucket-destination TargetBucketName
Note that the first parameter is the source CB server (http://10.10.10.68:8091) and the second one is the target CB server (http://localhost:8091). The value of the -b parameter is the name of the source bucket and the value of the --bucket-destination parameter is the name of the target bucket.
In order to run this command in Windows, you must first go to the following folder:
C:\Program Files\Couchbase\Server\bin\
If one prefers to use the cbbackupmgr and cbbackup tools which were mentioned in the other answers, one needs to have access to the file system, which in my case was not possible. But still both tools are also useful nevertheless and I appreciate their answers.
I'm starting to get a bit desperate in my attempts to get a ruby script to connect to MySQL.
I've given up on DBI, as I just don't seem to be able to get it to work no matter what I do. I figured I might have more luck with just using mysql.rb from ruby-mysql. However, in using that I get the following error:
./mysql.rb:453:in `read': Client does not support authentication protocol requested by server; consider upgrading MySQL client (Mysql::Error)
I gather from googling that error message that this means my version of MySQL is too recent and doesn't support old-style passwords. I'm on a shared server and don't have root access, so I can't make the changes recommended to the MySQL config.
My version, btw, is:
mysql Ver 14.7 Distrib 4.1.22, for pc-linux-gnu (i686) using readline 4.3
Has anyone succeeded in getting ruby to connect to MySQL? I've been trying under Windows, since I have admin access on my Windows machine, but if there's a way to do it without root access on Linux, that'd be even better.
Sounds like you've run in to a MySQL quirk. Some time around version 5.0 they changed the format of connect passwords. It's an easy fix, though: http://dev.mysql.com/doc/refman/5.1/en/old-client.html
(Also, check out the Ruby Sequel gem, it lets you do some real fun stuff with all sorts of databases and without the overhead of ActiveRecord: http://sequel.rubyforge.org/documentation.html )
There is a good summary of how to do this here: http://rubylearning.com/satishtalim/ruby_activerecord_and_mysql.html
I haven't had any issues with connecting to MySQL from Ruby on my test machines.
You mention that you're using a shared hosting provider. If they have that old of a ruby-mysql version that it's not compatible with the new style passwords, perhaps their support staff can make the changes you need made to the user row(s) in MySQL.
What are you looking to do? I think it is possible to use the ActiveRecord component of Rails to establish a connection to MySQL. I'll see if i can find some documentation to back this up, and i'll update this answer.
link to ActiveRecord/MySQL integration
Update: to use ActiveRecord for the purpose are looking for, you will need to create the various model classes that represent the tables you are pulling data from, and specify their relationships. Once that is done, you will be able to do something like:
SomeModel.find(:all, :conditions => ['some_column = ?', some_value]
I've used this approach in the past to provide my Rails apps with access to WordPress data.
It may be that you're using an older version of mysql and need to upgrade it.