I have a Quorum network setup with an older version where constellation is being used. I am trying to migrate the whole network to the latest version of Quorum.
I successfully migrated the constellation data to mysql using the tessera migration script provided in git.
But I am facing a typical problem when I am trying to migrate the data from geth i.e. the leveldb part. I copied the chaindata and lightchaindata folder from the old datadir/geth to new datadir/geth.
Now when I am trying to start the geth it is throwing an error stating that chainid cannot be used as 1, unfortunately the chainid of my existing network, which I want to migrate, is 1. I analysed the source code of the latest version of Quorum and found an explicit exception is thrown if the chainid is set as 1.
May you please help me to find a solution for this.
Still unanswered
I think the manual migration is the only option here.
Thanks,
Shamik.
Related
Some time after the release of Elm19 I published a library, which I needed for an Elm18 code base: thought2/elm-wikimedia-commons.
This worked well, it's listed in the community driven Elm18 package database: https://dmy.github.io/elm-0.18-packages/, can be installed and all good. Except the fact that the documentation is not shown in the package details, but that I heard is a known bug there. (But still I think this is very bad)
But the main problem is now, how to migrate the library to Elm 19: The actual migration steps are done and live in the master branch of the repo: http://github.com/thought2/elm-wikimedia-commons
The Elm18 versions proceeded to 1.1.0 in the meanwhile and after the migration there had to be done an API change, so I'd assume the latest version to become 2.0.0. If I add this to elm.json, the command elm publish tells me that this would be the first version and I should change this. Which is not right.
After a bit of research, I found out that the package (among other 18 ones that have been published in the same time period) is not listed in this json: https://package.elm-lang.org/all-packages This should contain all packages regardless of versions.
Any ideas what to do? This is really blocking my development, as I'm stuck in both lands now: 18 and 19. Would appreciate a lot if someone has some hints or solutions for me!
You shouldn't need to mess with the version number specified in elm.json.
If you set it back to the version of the package that is already published and run elm bump the elm program will look at the changes you've made to the package's API and set the new version accordingly.
Looking at https://github.com/thought2/elm-wikimedia-commons it doesn't look like any of your upgrade changes were breaking changes to your package API so the version won't be a 2.x.x, it will be a 1.x.x.
You'll need to remove the 2.0.0 git tag as well and instead add a tag for the version that elm bump tells you that your package is.
I had Erlang/OTP 17 and RabbitMQ Server 3.4.3 installed on my local windows box. Before upgrading to the newer versions in production, I wanted to give it a try on my local box to see if upgrade won't cause any problem. I am trying to upgrade them to the latest versions - Erlang/OTP 21 and RabbitMQ Server 3.7.8. When I do upgrade, I lost all my existing messages.
I had some existing messages in multiple queues. As soon as I upgraded Erlang/OTP (21), I see all my existing messages are gone. I even tried installing the newer RabbitMQ Server (3.7.8), still I don't see my old messages in the queues. I thought mnesia database would help in restoring the messages. I guess either I don't understand the concept or I am missing some settings.
I don't want our production clients complain about the messages being lost. I couldn't find much help online on this topic. But, surely RabbitMQ documentation talks about Blue-Green Deployment Strategy, never did that, so was not sure if that would help in our case, or it is an overkill and has a simpler solution. Also, want to add that I did all manual upgrade. If anyone know a better process of upgrade for single node without losing the existing messages, please guide and help me.
The documentation clearly states that you can't upgrade directly from version 3.4.3 to version 3.7.8: link. You must first upgrade to 3.6.16.
In your case, using a blue-green upgrade would be the only way to avoid having to first upgrade to version 3.6.16 prior to 3.7.8.
How do I save/commit/push such that the network has the latest version?
I have never used version control before.
I am new to Visual Studio 2015 (I mainly used VS 2005).
I am a VB.net developer.
I am running Windows 10 and have a Windows 2008R2 Server (not AD).
I need to keep my code private and local (no cloud).
I will eventually need to have up to 3 developers collaborate with my code.
I am not a fan of using the command line unless I absolutely have to. (GUI for me).
I feel that version control should be integrated with Visual Studio.
I think the code should be stored on the server and a local (working) copy on my machine.
I believe I would benefit from using Git. (Not GitHub).
I may also check out Gogs or Bonobo. I hate Java so not (Gitblit)
I Installed Git on my server - although I'm not sure I needed to do this.
I have installed it on my local machine.
I mapped a shared directory (v:)
I have attempted (successfully - I think) to copy my code into a repository and make a few commits.
I thought I was having some success using the Visual Studio 2015 - Built-It / Extension
However, after attempting to use/create a local clone eg C:\Users\My User Name\Source\Repos
Making some changes, Commit All, Then attempting to Push I get the following Error:
"Failed to push to the remote repository. See the Output window for more details."
Output window says:
"Error encountered while pushing to the remote repository: Local push doesn't (yet) support pushing to non-bare repos."
I've read but not sure how to apply to VS Git push error '[remote rejected] master -> master (branch is currently checked out)'
PS. Because of my specific set-up/needs I’m struggling to find help. Any tutorial recommendations are welcome.
Sorry if this is too verbose.
I had many problems trying to solve this.
One of which was attempting to use the Network Drive as the Master when I Believe the local is the Master.
I am sure that I am to much of a noob with this (even now), however just because it may help someone try bonobo git server. This allowed me to create a LAN based Git repository on windows that I seem to have got to work.
I still think that my problem was trying to find good help that was relevant to what I was trying to do was lacking (or I was looking in the wrong places).
We have a productive GitLab 6.8.1 running. I've set up a parallel VM with GitLab 7.10.4. Now I want to move all data from the old installation to the new one. I've already found a way how to move the bare repositories, but I have no clue how to import the user account information, issues, etc.
EDIT: The thing is further complicated by the fact that the original installation was built from source, was running on Debian, used MySQL as a database and the whole installation was pretty much messed up. That's why I didn't manage to migrate the old server and decided to set up a new one. The new server is an Ubuntu machine with GitLab installed from apt-get package (I think that's Omnibus, but I'm not sure what this means.) The new installation seems to use PostgreSQL.
FYI You haven't specified whether the old or new server is running a source installation or omnibus, or whether you're running a MySQL or Postgres database. Instructions differ depending on these factors, so please clarify and I will update my answer.
The first thing is that you will need your old and new servers to be on the same version of GitLab. You cannot migrate anything other than repos without having synchronized versions.
Depending on your reply to the above you will either follow instructions similar to the backup and restore tasks or by running the backup and restore tasks. Both options generally require you to manually copy configuration files or migrate settings from multiple files to a single new file (in the case of going from a source install to Omnibus). The Omnibus upgrade guide above lists the configuration files that need to be migrated depending on your environment.
Update based on edited question: There's a guide specifically for that scenario in this section of the Omnibus upgrade guide, using Option 2. You still need to have the same version on both old and new servers, though, I believe.
I'm developing several Rails 3.2 applications on Mac OS X Lion. Last night, I updated from 10.7.4 to 10.7.5, and I found this morning that I'm no longer able to connect to my development Postgresql databases (while my production environments are working just fine, with the same codebases). This is the case for all applications I'm developing locally which use PostgreSQL.
The error message I'm getting every time I try to connect:
PG::Error: could not connect to server: No such file or directory
Is the server running locally and accepting
connections on Unix domain socket "/tmp/.s.PGSQL.5432"?
I've read a few other SO posts about similar problems, but most of them suggest PATH changes in ~/.bash_profile. When I run which psql (as suggested in the other posts), though, /usr/local/bin/psql is returned, which is correct (according to the other posts).
I'm hesitant to uninstall and reinstall PostgreSQL again (even via Homebrew), as I don't want to mess with my existing PostgreSQL databases for all of my applications. (Perhaps that's not a potential problem—I'm not confident enough to say.)
I've uninstalled and reinstalled the pg gem several times, closed and reopened my shell session, restarted my machine (and every combination thereof), all to no avail.
Where can I go from here?
Your issue is that PostgreSQL is not running. First I highly recommend backing up PostgreSQL db's before doing OS upgrades because sometimes things don't go well. If you have a dump, you have a lot more options if things go south. I do agree that recompiling on a new OS poses some questions regarding your existing dbs.
The first thing to do of course is to try to start PostgreSQL normally. Maybe it is just missing a startup script. Something like sudo -u postgres pg_ctl -D /path/to/postgresql/data/dir
If that doesn't work you need to look at the error message and try to resolve that. Hopefully it works without problem. If it doesn't work copy your data directory, if you can, to a system running the old version. Try to dump it from there. After you have your copy (important, back up files first!) you may see if you can get pg_upgrade to work. If that fails, try to compile (via homebrew) the same major version you were running before.
If that fails, hire an expert.