opengauss 2.0.1 Enterprise Edition, one master and one backup, one-level backup
Environment: try to install in 3 virtual machines of VBOX on the notebook, each virtual machine has 4G memory.
Error during installation: It is probably a problem with memory allocation, and the database cannot be started.
After manually adjusting the shared_buffers to 256M, execute
“gs_om -t start to start”.
each node library, but there is still a memory problem (but not the same as the initial gs_install installation).
and the cluster status is abnormal, indicating that it needs to be repaired. Don't know how to deal with it.
error message：
Failed to start cluster. After startup,the last check results were Degraded. Please check manually.
I guess the memory is too small, you can give it to 8G and try again.
Related
I was trying to upgrade my postgres installation from 9.5.7 to 9.6.5
My postgres database production instance has several databases and consumed ~700 GB space till now.
pg_upgrade needs 2 different dir for old and new datadir.
pg_upgrade -b oldbindir -B newbindir -d olddatadir -D newdatadir
it needs a new directory to do the pg_upgrade where as I was able to run the above command in my local/stage database as my database size was small in comparison to prod and I observed the following in my local
sudo du -sh /var/lib/pgsql/data-9.5
64G /var/lib/pgsql/data-9.5
sudo du -sh /var/lib/pgsql/data-9.6
60G /var/lib/pgsql/data-9.6
and I was having sufficient free data space to do the interim pg_upgrade process in my local/stage and I did it successfully there.
While in production I have only ~300 GB free space.
However after the successful upgrade we will delete the /var/lib/pgsql/data-9.5 dir.
Is there any way to do the in-place data upgrade so that It will not need the same amount of extra space for interim pg_upgrade process ?
Run pg_upgrade
/usr/lib/postgresql/9.6/bin/pg_upgrade
-b /usr/lib/postgresql/9.5/bin/
-B /usr/lib/postgresql/9.6/bin/
-d /var/lib/pgsql/data-9.5/
-D /var/lib/pgsql/data/
--link --check
Performing Consistency Checks
-----------------------------
Checking cluster versions ok
Checking database user is the install user ok
Checking database connection settings ok
Checking for prepared transactions ok
Checking for reg* system OID user data types ok
Checking for contrib/isn with bigint-passing mismatch ok
Checking for roles starting with 'pg_' ok
Checking for presence of required libraries ok
Checking database user is the install user ok
Checking for prepared transactions ok
Clusters are compatible
Always run the pg_upgrade binary of the new server, not the old one. pg_upgrade requires the specification of the old and new cluster's data and executable (bin) directories. You can also specify user and port values, and whether you want the data linked instead of copied (the default).
If you use link mode, the upgrade will be much faster (no file copying) and use less disk space, but you will not be able to access your old cluster once you start the new cluster after the upgrade. Link mode also requires that the old and new cluster data directories be in the same file system. (Tablespaces and pg_xlog can be on different file systems.) See pg_upgrade --help for a full list of options.
Thanks to the postgres community comprehensive documentation which helped me a lot to find the solution after all.
just curious:
I see in my school that all instances of SQL Server ( and other programs) are installed in a Virtual Machine. Is there a reason to install software in a VM instead of directly into the machine's hard drive? I assume it may be a matter of faulty installation of software somehow affecting the host PC , while if there is a problem within the VM, the VM can just be deleted and the problem disappears, without affecting the host. Is this it, or is there more to it?
From a lab administrator's standpoint, it would be FAR easier to administrate multiple VMs in a classroom/lab setting.
Here is one great example (among others):
At the start of the semester, the admin can make a clean install (new OS, new SQL Server, etc.) on a new VM. Once the machine has everything needed, he can take a snapshot of the VM. After that, he can assign you to use that VM to your heart's content: Create DBs, install games, infect the OS, whatever.
When you have finished your studies, the admin can then easily apply the snapshot, and, voila, the VM is back to the original state as when it was given to you earlier. No reformatting, no uninstalling, etc.
Also equally compelling: From that one initial VM image, an admin can clone as many VM copies as needed (one step) without having to go through the minutae of installing/configuring software over and over.
I have installed a fresh instance of AX 2012 R3 on my system. When I try to start the service on my machine i get the following error:
Note: When I try to start the service through Local system it works. But I want to start it through the account NT Authority/Network Service. Any suggestions?
Another anomaly is that when i try to install DIXF it gives me the following error: "Verify that you have enough privileges to start the service"
It sounds like you've narrowed the issue down yourself. Do you need to have it running as the network service account? Run it as your user or another user with access to SQL.
I'd say that it's a permissions issue to SQL and/or file permissions on the machine the AOS resides on.
https://technet.microsoft.com/en-us/library/dd362055.aspx
Debugging a crashing AOS server is not a simple task.
As I see from your Event Log you are running build number 6.3.164.0 which is the RTM build of 2012 R3. Many hotfixes have been released since and there is a good chance your problem goes away with just installing the latest kernel build. See Overview of Microsoft Dynamics AX build numbers for links to more recent builds.
Running a newer kernel with an older application build is supported, but since it's a fresh instance I'd update the application too.
If you would have a go at debugging this yourself you could try to get a memory dump to analyze with windbg. Refer to this article So your AOS crashed, is hanging, or you just want to see what it's doing .
Unfortunately my results with that approach have been mixed. Unfortunately we don't have access to all debugging symbols we need, and in this case, since it crashes immediately on startup I don't know what to expect.
Your third and last option is to open a support ticket with Microsoft and provide them with memory dumps, but their suggestion will be to update to a more recent build anyway.
Box was corrupt and was cleaned up and operational. Now, SQL Server will not connect to my db. I checked services and found that mssqlserver, SQL Server agents won't start. Gives error
Cannot connect to local server
They are set to automatically start, but manually starting gives the same error.
I cleaned his box with this recipe that I use successfully on dozens of computers. All other software is running fine. His box also had a failing disk so I xxcloned (XXClone.com) his disk to a fresh new disk. I believe the cleaning is an unrelated issue, but whatever it takes to fix it we are happy to try. I know many people with this SQL Server issue, and over the years have fixed it a few ways, but I am tight on time, so I suggested he get help here.
THOROUGH BADDY CLEAN. Clean a Windows Machine without Formatting it or losing Data
STEP 1
If Ransomware or some baddy is taking over our MBR or Partition so you cannot escape it, and cannot run safe mode, the ICE Ransomware being one of many examples.....
http://www.bleepingcomputer.com/virus-removal/remove-ice-cyber-crime-center-ransomware
use a empty USB stick and HitManPro (the free version will remove)
http://www.surfright.nl/en/hitmanpro/
STEP 2
Reboot in Safe mode with networking by rebooting and holding down F8 key. None of this will permanently fix your computer unless you are in SAFE MODE w/ NETWORKING
Download RKill and run it
Download ComboFix from BleepingComputer.org and run it
Download SmitFraudFix and run it
Download AntiMalwareBytes to catch everything those did not
I can clean any machine no matter how badly infected with these tools in safe mode. Will keep recurring if attempted in Normal Mode. Safe mode is the key.
My EC2 database server failed, preventing SSH or other access (not sure why ... grrr AWS ... that's another story).
I was able to make a snapshot of the EBS root volume. I can not boot a new instance from this volume (I'm guessing the boot partition is corrupt). However, I can attach and mount the volume on a new instance.
Now I need to get the PostgreSQL 8.4 on the new machine (Ubuntu 10.04) to load the data from the mounted volume. Is this possible? I've tried:
pg_ctl start -D /<mount_dir>/etc/postgresql/8.4/main/
But no joy ... PostgreSQL just starts with empty tables.
Is /etc/postgresql/8.4/main/ the correct location for PostgreSQL data files?
Is there a way to recover the data from the mounted volume in a way that PostgreSQL can read again?
(You should really specify your distro and version, etc, with this sort of system admin question.)
Running Pg via pg_ctl as shown above should work, assuming the original database was from Pg 8.4 and so are the binaries you're trying to use to start it. Perhaps you forgot to stop the instance of PostgreSQL automatically started by the distro? Or connected on the wrong port, so you got the distro's default instance instead of your DB on another port (or different unix socket path, for unix sockets)?
Personally I wouldn't do what you're doing anyway. First, before I did anything else, I'd make a full backup of the entire data directory because you clearly don't have good backups, otherwise you wouldn't be worrying about this. Take them now, because if you break something while restoring you're going to hate yourself. As demonstrated by this fault, trusting Amazon's storage (snapshot or otherwise) probably isn't good enough.
Once you've done that: The easiest way to restore your DB will be to, on a new instance you know you don't have any important data on that has the same major version (eg "8.4" or "9.0") of postgresql as your original instance did installed:
/etc/init.d/postgresql-8.4 stop
datadir=/var/lib/postgresql/8.4/main
rm -rf "$datadir"
cp -aR /<mount_dir>/etc/postgresql/8.4/main/ "$datadir"
chown -R postgres:postgres "$datadir"
/etc/init.d/postgresql-8.4 start
In other words: take a copy, fix the permissions, start the DB.
You might need to edit /etc/postgresql/8.4/main/postgresql.conf and/or /etc/postgresql/8.4/main/pg_hba.conf because any edits you made to the originals aren't there anymore; they're on your corrupted root FS. The postgresql.conf and pg_hba.conf in the datadir are just symlinks to the ones in etc under Debian - something I understand the rationale behind, but don't love.
Once you get it running, do an immediate pg_dumpall and/or just a pg_dump of your important DB, then copy it somewhere safe.