Topic: MySQL Connections
Specific Question: In a 2-3 week process of learning MySQL and attempting to get a Python stock info scrapping program to feed data into a MySQL schema (database, table) I’ve ended up creating a number of connections. (MySQL57, MySQL57_1,MySQL57Nov13) Even though I believe I’ve deleted the connections through Workbench, they still show up as Window services. How do I completely get rid of these beasts, both in MySQL and as Windows services?
System: Windows 8 64bit on a Xeon Ivy Bridge processor, large SSD’s, large HD’s, mucho RAM, dual X-fired video cards, ASUS Sabertooth MB (self-built a yr ago)
Software: MySQL 5.7, complete installation except for module for Visual Basic and Python3 (running 2.7). Attempting to use the above hardware as both a server & client.
Even though I did my first Fortran programming in 1964, and spent my career on Unix machines, please regard me as a newbie when it come to the jargon associated with databases and client/server communications.
Why am I asking this question? My “down the road question” will be about getting data from Python into the MySQL table, but “first things first” --- I would like to get a nice clean installation & am concerned with these connections showing up as windows services.
By the way, I’ve thoroughly scoured this site and many others but have not found any answers that fit my requirements; they’re either for a non-Windows environment, too full of jargon for me to understand, or too simplistic to be useful. Hope that didn't come across wrong :-)
TIA, Doug
You found the uninstallation command already, so let me show you how to make sure not to remove the wrong service.
Open the services management (e.g. via Start menu -> Computer -> right click -> Manage -> Services and Applications -> Services). Scroll to the MySQL server services and double click one that you want to uninstall. A dialog opens with various information about the service including a line "Path to executable:". The followoing line contains the full path to the server this service is for. You should only have one service for each of the servers. If that is not the case then you probably have to go through the registry and search for the service name and remove that key manually, until only one is left. Otherwise just use the path to run your uninstallation if that is for a server/service you don't want anymore.
My problem (as described in my original question) has been solved thanks to the comments that Michael made.
In a command prompt with admin privileges
net stop MySQL57Nov13 (service name)
to stop the service (all 3 of my services)
Note: I had cd'd to D:\Program Files\MySQL\MySQL Server 5.7\bin to run the net stop
commands. I have a hunch that the commands would have worked independent of the directory chosen
to run them from....didn't experiment further though. Likely depends on the PATH env var.
Then go to C:>
sc delete MySQL57Nov13
for all 3 services I wanted to delete
As a reference I used http://dev.mysql.com/doc/refman/5.7/en/windows-troubleshooting.html
The above was written prior to Mike's answer.
Later update: This is a *%#&!! nightmare! Obviously I deleted the key windows service (was one of MySQL57, MySQL57_1, or MySQL57Nov13). This effectively cratered the entire project ... couldn't create a new, fresh connection or anything else. So I uninstalled everything (to the best of my knowledge) using the internal MySQL Uninstall routine as opposed to Windows Program Management uninstall. Fortunately I've got no data which I have to save.
I'll start a new question later today.... I'm going to uninstall the mess again, and start from scratch (the new question will be concerning the MySQL import hanging when I tried to import a .sql file tied to a tutorial I've been watching)
Let's consider my Question solved with many thanks to Michael and Mike
Related
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 :)
Specific Question: In a 2-3 week process of learning MySQL and attempting to get a Python stock info scrapping program to feed data into a MySQL schema (database, table) I’m having serious difficulties with connections. Having been bitten by doing something wrong & having to re-install MySQL about 8 times now, I’m getting rightfully leery of just about everything in the installation process. Thus this question:
Is “Local instance MySQL” which shows up in the upper left corner of the first (black) MySQL Workbench screen the proper one to use to connect to the database?
As a follow-up,
What is the difference between the windows service MySQL57, the connection MySQL57, and Local instance MySQL57?
During the very painful process of trying to get MySQL up and running, I think I've gotten further when with a fresh installation the first screen reads “MySQL57” as opposed to “Local instance …”
My setup parameters are pretty vanilla with the exception that I’m putting the MySQL program on my D: drive as opposed to the C: drive (an SSD reserved for the operating sys).
System: Windows 8 64bit on a Xeon Ivy Bridge processor, large SSD’s, large HD’s, mucho RAM, dual X-fired video cards, ASUS Sabertooth MB (self-built a yr ago)
Software: MySQL 5.7, complete installation except for module for Visual Basic and Python3 (running 2.7). Attempting to use the above hardware as both a server & client.
Even though I did my first Fortran programming in 1964, and spent my career on Unix machines, please regard me as a newbie when it come to the jargon associated with databases and client/server communications.
Why am I asking this question? My “down the road question” will be about getting data from Python into the MySQL table, but “first things first” --- I would like to get a nice clean installation that I can trust.
By the way, I’ve thoroughly scoured this site and many others but have not found any answers that fit my requirements; they’re either for a non-Windows environment, too full of jargon for me to understand, or too simplistic to be useful.
TIA, Doug
Seems there's some confusion about certain terms. So let's have a look at each:
MySQL is a server application that you can install and connect to via
TCP/IP (on any platform), named pipes (on Windows) or sockets (on
*nix like platforms). This server is totally independent and has no name or such for identification.
A Windows service to run the MySQL server: this is just a helper to allow running the server when your machine starts up. A service is not strictly necessary to run a MySQL server but without it you would have to manually start/stop the server. You can create as many service entries for a server as you want, but usually it makes no sense to create more than one. Since there can be more than one server (each with an own service) on the box it is highly recommended to give the services speaking names (like MySQL57 for a 5.7 MySQL server, MySQL56 or a 5.6 server etc.).
MySQL Workbench connections are entries that store parameters to connect to a MySQL server. They are not tied to a specific service in general (you can connect to a non-Windows server too), but might be associated with such a service if they are configured for a local server (on a Windows machine) and you want to be able to start/stop this server from within MySQL Workbench (see Administrator section). They use the service name to act on a particular service (you configure that in the Connection manager, System profile). On Windows MySQL Workbench attempts to find installed service (to help new users to get up and running quicker) when it is started and no connection is currently defined. It then automatically creates a connection for each service it found (it uses "mysql*" as pattern to search for services). You can retrigger this process by removing all connections and restart MySQL Workbench.
The created connnections (like the “Local instance MySQL”) appear as tile you can simply click to open that connection. Be aware that clicking on the rightmost 1/4 of the tile will open an information popup only, not open the connection as such.
Now to your question:
What is the difference between the windows service MySQL57, the
connection MySQL57, and Local instance MySQL57?
I don't understand where you see a connection MySQL57. There's usually only a service MySQL57 and connection in MySQL Workbench to the server this service is for involved.
I'm also not sure why this is such a dreadful process for you. Especially for Windows a lot of effort has been put into an easy installation experience. The normal process should be like:
Download the MySQL Installer
Run the installer. Select a typical scenario from the presets or select the individual products you want to have installed, say, a MySQL server + MySQL Workbench.
The installer will download and install the selected components.
Configure your server (like giving it a proper service name, TCP/IP port etc.).
After finishing the installer you start MySQL Workbench and can immediately work with your new server (as described above MySQL Workbench picks up the service automatically).
Depending on your download speed this should be something like a 5 - 10 mins. process.
HTH
with due respect sir , windows service mysql is a service created by windows upon successful to help you start / stop mysql. You can use Local Instance Mysql57 without a glitch, as that is just a way of MySQL representing your local mysql instance in the workbench.
My father has a small business and asked me to make him a quick program to help automate several of his daily tasks. Due to the nature of these tasks, it absolutely requires a local database (not distributed with connections from multiple clients, just 1 local client and 1 local MySql datastore).
I'm pretty accustomed to MySql programming but have never had to install it and don't really know the details about how it works under the hood.
What I'd like to have is a final deliverable where I send him a folder that has an executable JAR (I've chosen Java since its a good fit here) as well as a preconfigured MySql database on it. I'll run all the scripts, initialize all the tables and populate them, etc. before deploying the the distributable (folder).
This way, no config is necessary for him. My dad gets the folder, plunks it down wherever he wants it on his file system, and double-clicks the JAR to launch the program every time. I will preconfigure the JDBC code to look and connect to the local Mysql database also living under the same root folder ("MyDadsApp/").
Is this even possible to do? If not, why? If so, how?
Here's what I'm thinking as a tentative deployed folder structure:
MyDadsApp/
MyDadsApp.jar
res/
user-manual/
mysql/
MyDadsAppDatabase.myd (???) - the actual database
MySql.exe (???) - MySql Server
Any input/recommendations will be met with open arms!
Thanks
This is actually a perfect scenario for SQLite. It's got a lot less features than MySQL, but it's whole shtick is that it's server-less and self-contained. Sounds perfect for what you're doing.
I'm faced with a task I don't know how to proceed with: migrate a 120 GB database from PROGRESS to SQL Server 2008.
I've quite frankly never even heard of PROGRESS and can't really make much sense of their web site either.... what I have is a folder restore with 128 files called dbqsXXX where XXX goes from 1 through 128 - each file is 1 GB in size.
I don't know PROGRESS, I don't have any PROGRESS server available - is there any hope I can get the data out of these files into SQL Server??
Also: I tried to find ODBC drivers, and I found one (called SequeLink ODBC 4.51), but I cannot install it since it doesn't like my Win7 x64 machine :-( And on the PROGRESS site itself, I cannot seem to find any ODBC driver for download - only stuff that will cost $$$$$$
So - what are my options??
is there something like a "PROGRESS Express" or "Free" or "Developer" version available?
can I access those dbqs files in my "restore" directory some other way?? They appear to be at least partly binary - no CSV or XML or anything like that.....
can I find a useable ODBC or OleDB driver that will work on my Win7 x64 machine and allow me to create a linked server to the PROGRESS db?? (worked fine with MySQL a while ago)
can I (or my customer) somehow dump the structure and data from PROGRESS into another, more approachable format, like MySQL or PostgreSQL or something??
Any hints, tips, website, webcasts are most welcome !!
There is an evaluation kit available: http://communities.progress.com/pcom/docs/DOC-103695
This may, or may not, help you depending on what those files that you have actually are. If they are a complete and uncorrupted copy of a recent version of the database then the evaluation kit should be able to open them.
It is, however, possible that the database has been protected from such access. In which case you could be out of luck unless you can obtain credentials from whoever controls them.
Having said that -- your description of the file names does not sound like an actual database. Database extents are usually named something like dbname.db, dbname.b1, dbname.d1, dbname.d2 etc. If the db was configured using storage areas many of the extents will be named dbname_##.d#.
Your files sound more like they are "backup extents". In other words they are the result of someone making a backup and writing it in 1GB chunks. To restore such a backup you need a text file that lists all of these "extents" except for the first one. You would then execute the following:
prorest dbname extent1 < filelist
(Use the "proenv" shortcut to get a properly configured command window.)
Once you do that you would have an actual database. (If the backup was made with compresssion the restored db is likely to be a lot bigger than your files.)
Prorest is not backwards compatible. So if the backup is a v9 database the v10 evaluation kit won't work. You would need to find a machine with the same version of Progress that the backup was made with. (There are v9 utilities in the %DLC%\bin\91dbutils folder. Ditto v8 in 83dbutils. In theory you could use those to restore a backup of an old version and upgrade to a current version. Actually using those utilities is "challenging".)
Given an actual database you can then start a server with "proserve", connect to it and have fun. But right now isn't clear if there's any point to getting into the details of doing that.
I have done my best to install a copy of SQL Server 2008, but have discovered my "Reporting Services" installation has failed.
Furthermore, when I attempt to "repair" both the installation (and the "Shared Components" only, per a work-around I found here, will update with link if I find it) I have no had any success, as the SQL Server 2008 SP1 Patch reports that there are issues with my server's previous installation.
When I follow the procedure to complete uninstall SQL Server 2008 for a clean install (following instructions such as removing all components via the control panel "Uninstall") I also recieve errors, and when I attempt to re-run the installer I find that the instance I previously attempted to remove still exists: "MSSQL10" for example (see screen shot), and "RS" is listed as it's components, leading me to believe that the uninstall is failing because of this "RS" issue!
I have redownloaded the installer media, and tried to re-running it, and get the same issues when I choose a new name for an instances, and try "adding" features to the one I CANNOT seem uninstall! Any advice would be very helpful, my goal is to uninstall all instances of SQL Server 2008, start fresh, and apply the SP1 patch.
Thanks. I have attached log file, and screen shot. Computer information: Windows 7 Pro.
HP G60
Some error messages:
TITLE: SQL Server Setup failure.
Input string was not incorrect format.
I have pictures but not enough "reputation" to post them )-8
I experienced this problem as well - someone suggests it is corrupted Perfmon counters:
I found this ( http://social.technet.microsoft.com/Forums/en-US/sqlsetupandupgrade/thread/c9cb944d-6264-4530-9e00-ee92da3e939f/ ):
================================
Got this one figured out. The performance counters were corrupted. You can see this by opening perfmon and noticing a bunch of numbers instead of the actual counters themselves.
In order to fix (or you might want to check before you install), run:
c:\windows\system32\lodctr /R
This will reload the performance counters
This worked.