New answers tagged

0

Several repeated attempts with 3.0 SP2 linked in the question and lots of SQL/ Regitry & Server/ IIS settings and nothing worked. I must've read 100s of articles, blog posts and the downloaded SP2 would just not get installed despite lots of manual hacks / registry/ DB changes/ permissions / folder and file manipulations. I will post more links of ...


0

or if your got replication > 1, simulate a dead node and then bootstrap it with new SSD layout and get it rejoining the cluster.


1

Apparently the fix I did was pretty brute force and might be dumb, but it works anyway. I did sudo find / -iname "pgdg95". Ran rm -rf on all the folders and files listed. Repeated the steps listed above and it installed fine. This answer helped me to get it up and running.Also had to change hba.conf.


0

As it turns out, when I copied over /var/lib/mysql from my old system, the permissions weren't corrected, resulting in nginx not having read access to the directory containing the socket file for MariaDB. The solution was to update the permissions on /var/lib/mysql so nginx had access.


1

It sounds as the underlying disks are busy. The problem in restoring a large database is that each (group of) INSERT requires a flush/sync operation, which is very slow on mechanical disks (a 7200 RPM disk is in the order of ~100 IOPS). To hasten the restore, you had to temporarily instruct MySQL/MariaDB to not issue flushes/syncs. To do that, interrupt the ...


1

If your underlying storage is plain old disks, for a 25GB-on-disk MySQL database, that's quite normal to experience hours-long restore - especially for some badly structured dbs (lots of tuples, indexes, etc.). For a start compress your dump, that saves tons of I/Os and puts less stress on cache memory : mysqldump foo |gzip >foo.sql.gz zcat foo.sql.gz ...


0

Problem is related with a bug in versions prior to 2.1 (https://issues.apache.org/jira/browse/CASSANDRA-5911). Commit logs are not removed after a flush.


1

Mysqldump won't have any options to dump only on views.The below command will help you to take the backup of only views. mysql -uroot -pPassword INFORMATION_SCHEMA --skip-column-names -e "select table_name from tables where table_type = 'VIEW' and table_schema = 'sakila'" | xargs mysqldump -u root -pPassword sakila > only_views.sql


0

Check if there are any other nodetool processes running. I've had drain hang when there are snapshots processes backing up. I stopped them all and restarted Cassandra to make sure it was healthy, then drain worked.


0

While Cassandra is running, rsync from HD to SSD. Make sure you use the -H and --delete flags to address hardlinks and deleted sstables/commitlogs. Don't forget commitlogs if they're on the same device. Once you get to a point where you've transferred the bulk of the data and subsequent rsyncs complete relatively quickly, you can drain & stop that ...


0

For a fool-proof strategy you can try proxmox, so you virtualize your dedicated server and can take advantage of kvm virtualization if planning to use Windows os, or lxc for recent linux distro. Then you can easily snaphot each VM into external ftp/nfs + some 'ol good file level backup (attic backup, acronis, rsync, rsnapshot, rdiff backup, bacula, and so ...


0

Short answer for AWS services that load DBF : NO Longer answer : RDS services doesn't support DBF file types. One issues of DBF is, there is no standard. A dbf can be from ANY database engine, format is varied. If you want CORRECT answer, you must specify what DB engine it is, and not all db engine will recognise them. If you have an apps or DB engine that ...



Top 50 recent answers are included